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EXECUTIVE  SUMMARY 

Computer  software  is  a  necessary  element  in  Army  weapon  systems  but  that 
software  is  contributing  an  inordinate  amount  of  cost  and  risk  to  system 
acquisition.  This  report  identifies  the  problems  which  the  Army  is  facing  and 
will  continue  to  face  unless  corrective  actions  are  taken.  The  report  builds 
on  a’ld  Is  consistent  with  a  number  of  previous  studies.  Investigations,  and 
reports.  It  identifies  recommended  actions  and  calls  on  the  Army  to  establish 
an  orderly,  task-oriented  assault  on  the  problems. 

The  report  suggests  there  are  three  primary  challenges  to  the  Army:  reduce  the 
growth  in  the  cost  of  software  the  Army  is  acquiring,  bring  the  process  to 
develop  and  maintain  software  under  control,  and  maintain  and  extend  the 
technological  superiority  of  Army  weapon  systems  through  a  focused  investment 
in  software.  A  taxonomy  of  software  problems  is  presented  which  groups 
today's  software  problems  into  five  areas:  capability  of  people,  absence  of  a 
clear  and  cogent  software  policy,  lack  of  process  controls,  an  absence  of 
adequate  procedures,  and  failure  to  capitalize  on  and  plan  for  technology. 

The  report  recommends  an  Integrated  course  of  action  to  try  to  gain  control  of 
the  software  in  the  Army's  software  systems.  The  recommendations  call  for  the 
Army  to:  develop  a  strategy  for  software  acquisition,  organize  to  better 
manage  the  acquisition  and  support  of  software  intensive  systMS,  establish 
controls  to  guide  programs  and  manage  system  acquisitions,  and  allocate 
sufficient  resources  for  mission  critical  software.  An  implementation 
strategy  is  suggested  which  provides  for  intensive,  dedicated  management  until 
significant  progress  is  demonstrated. 


TABLE  OF  CONTENTS 


SECTION  I  -  Introduction 

I .  I  Background  . 1 

1. 2  Plowing  Old  Ground  .  2 

1.3  Task  Force  Methodology  . 3 

1.3.1  Issue  Identification  . 4 

1.3.2  Problem  Analysis  .  5 

1.3.3  Proposed  Solutions  . 6 

1.4  Issues  .  7 

1.4.1  People  . 7 

1.4.2  Policy  .  8 

1.4.3  Process  .  9 

1.4.4  Procedures  . 10 

1.4.5  Planning  .  II 

SECTION  II  -  Problems 

2.1  Challenge  to  the  Army  .  13 

2.1.1  Cost  of  Software  .  14 

2.1.2  Product  and  Process  Control  . .  IS 

2.1.3  Technological  Advantage  .  17 

2.2  Taxonomy  of  Problems  .  18 

2.2.1  People  .  19 

2.2.2  Policy  .  20 

2.2.3  Process  .  21 

2.2.4  Procedures  . 21 

2.2.5  Planning  .  22 

SECTION  III  -  Recommendations 

3.1  Taking  the  Initiative  .  23 

3.1.1  Develop  a  Strategy  .  24 

3.1.2  Organize  to  Manage  .  25 

3.1.3  Establish  Better  Controls  .  26 

3.1.4  Resource  Allocation  . 27 

SECTION  IV  -  Implementation 

4.1  No  more  Band  Aids  . 29 

4.1.1  Planning  Templates  . . 29 

4.1.2  Detailed  Planning  .  30 

4.1.3  High  Priority  Tasks  .  31 

4.2  Implementation  Organization  .  32 

APPENDIX  A  -*  Software  Problem  Taxonomy  . A-l 

APPENDIX  B  -  Recommended  Actions  .  B-*l 

APPENDIX  C  -  Implementation  Obstacles  and  Schedules  .  C~1 


SECTION  I 
Introduccloo 


"Many  previous  studies  have  provided  an  abundance  of  valid 
conclusions  and  detailed  recommendations.  Most  remain 
unimplemented.  If  the  military  software  problem  is  real,  it  is 
not  perceived  as  urgent.  We  do  not  attempt  to  prove  that  it  is, 
we  do  recommend  how  to  attack  it  if  one  wants  to". 
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July  1,  1987 


1.1  BACKCtOOND 

Computer  software  used  in  Army  weapons  systems  Is  a  critical 
element  in  today's  battlefield.  It  is  the  computer  with  irs 
requisite  software  which  serves  as  a  force  multiplier.  lo  far 
too  many  Instances,  however,  computer  software  problems  appear  to 
have  caused  systems  to  be  delivered  late,  over  budget,  sod  with 
severe  problems  which  appeared  during  testing  or  in  the  field. 
The  challenge  to  the  Army  is  straightforward.  It  must  ensure 
mission  critical  software  is  planned,  designed,  developed, 
acquired,  Integrated,  tested,  fielded,  and  supported  so  the  Army 
can  meet  its  battlefield  objectives.  For  this  to  happen  the 
software  must  meet  quality  and  performance  requirements,  be 
available  on  a  timely  basis,  and  impose  an  acceptable  life  cycle 
cost  burden  on  the  Army.  Some  software  Initiatives  have  been 
taken  to  these  ends,  but  much  more  remains  to  be  done. 

Although  progress  has  been  made  in  recent  years,  the  Army  still 
does  not  have  a  cogent  software  acquisition  and  support  policy 
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nor  does  ic  have  a  strategy  for  insertion  of  new  technology  in  a 
controlled,  purposeful  manner.  Over  the  past  several  years, 
aspects  of  the  Army's  software  engineering  process  have  been 
documented  in:  Army  Post  Deployment  Software  Support  concept 
plans.  Joint  Logistics  Commanders  sponsored  go ve r nmen t / ind us t r y 
workshops  and  reports.  Army  and  Defense  Science  Board  studies', 
various  Army  Audit  Agency  and  Inspector  General  reviews,  and  a 
variety  of  DoD/service  sponsored  studies  of  software  management. 
Many  of  the  issues  are  clear.  This  Task  Force  has  been 
established  to  address  them. 

The  AMC  Software  Task  Force  was  chartered  to  document  the 
software  problems  which  will  confront  the  Army  through  the 
remainder  of  the  century  and  identify  initiatives  which  must  be 
taken  to  correct  them.  It  has  identified  mission  critical 
software  problems,  categorized  the  problems  into  action  areas, 
proposed  recommended  actions,  and  prepared  a  plan  to  bring 
software  under  control.  The  Task  Force  built  on  previous  studies 
to  the  maximum  extent  possible;  used  a  broad  perspective  tc 
address  all  aspects  of  the  software  problem;-  and  developed  a 
focused,  orderly,  task-oriented  plan  tb  address  Army  software 
problems . 

1.2  PLOVIMG  OLD  GtOOMO 

As  noted  in  the  1987  Defense  Science  Board  Task  Force  Report  on 
Military  Software,  there  has  been  a  plethora  of  previous  studies, 
investigations,  and  reports  documenting  the  problems  with 
battlefield  systems  and  offering  solutions  to  the  U.S.  military 
software  problem.  This  Task  Force  did  not  attempt  to  reinvent 
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all  of  the  work  that  has  gone  before.  Much  of  it  was  very  good. 
Rather,  the  approach  taken  was  to  review  the  earlier  findings, 
conduct  further  Investigation  where  necessary,  and  assemble  a 
coherent,  comprehensive  set  of  issues  and  pro.lems. 
Approximately  40  documents  were  identified  to  serve  as  a  basis 
for  this  effort.  Figure  1.1  shows  Che  number  of  documents  which 
fell  into  each  of  five  categories.  The  specific  references  are 
listed  in  Section  V  of  this  report. 


Government  investigations  and  Audits 

7 

Independent,  Joint,  arxj  Industry  Studiee 

8 

Army  Sponsored  Studies  and  Analyses 

8 

Memoranda,  Briefings,  and  Papers 

8 

Planning  and  Implementation  Documents 

7 

38 

figura  1.1  -  SMirea  OaoHMiNt 


1.3  TASK  rOKCB  MBTHODOLOGT 

The  Task  Force  went  through  a  four  step  process  la  order  to 
formulate  its  recommendations  and  propose  an  approach  to 
implement  Che  proposals.  Issues  were  identified,  the  Issues  were 
analyzed  to  determine  underlying  problems,  solutions  were 
proposed,  and  a  management  approach  for  laplemencac Ion  was 


sugges  ted  . 

Each  of 

these  steps  is 

described 

in  more 

detail 

below. 

Several 

categories  for 

Issues, 

problems 

,  and 

recommendations  were 

defined.  There 

was,  however,  no 

1-to-l 

mapping  of  issues'to-'problems  and  probleas**co-recoaaendac  loos . 
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The  issues  and  their  solutions  transcend  simple  categories.  For 
example,  training  and  education  issues  may  stand  alone,  but  their 
implications  ripple  into  areas  such  as  senior  leadership 
awareness  cf  software  issues  and  the  ability  to  make  informed 
decisions  on  policy,  funding,  and  planning.  The  best  way  of 
representing  the  interrelationships  between  these  Issues  is  with 
a  network  diagram  as  shown  in  Figure  1.2.  In  order  to  provide 
visibility  into  these  relationships  during  the  study,  a  database 
was  constructed  which  establishes  and  tracks  the  linkages.  The 
database  contains  the  full  text  of  the  recommendations  and  shows 
the  problems  and  Issues  they  were  Intended  to  solve.  It  Is 
recommended  that  this  database  be  used  as  one  of  the  management 
tools  to  assess  and  track  the  effectiveness  of  the  Implementation 
of  this  study.  The  steps  the  Task  Force  followed  are  outlined 
below. 

1.3.1  Issue  Ideatlf icaClom. 

Existing  problems  In  the  development  and  support  of  mission 
critical  computer  software  were  Identified  and  validated. 
Maximum  use  was  made  of  existing  studies / surveys . 

a.  Previously  completed  studies,  plans,  and  reports  were 
collected  and  the  issues  identified  In  them  were  cataloged. 
These  studies  Included  PDSS/LCSE  concept  plans,  JLC  Orlando  I/Il 
reports.  Army  Ada  Introduction  plans,  Army/Defense  Science  Board 
software  studies,  GAO/AAA/DAIG  software  reviews,  and  others  as 
shown  In  Section  V. 

b.  Issue  Information  was  updated  with  data  from  ongoing 
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management  and  software  cost  identification  efforts. 


c.  Issues  were  categorized  into  the  five  areas  of  concern 
identified  in  the  Taslt  Force's  Charter  (people,  policy,  process, 
procedures,  and  planning),  recent  or  ongoing  actions  to  resolve 
them  were  identified,  and  the  Issues  were  used  to  define 
underlying  problem  areas.  * 


ISSUES  UNDERLYING  RECOMMENDED 

PROBLEMS  SOUJnONS 


RgMral.S  -  S«ll«rar»  Tatk  Fore*  Prodad* 


1.3.2  Probloo  Analysis. 

A  comprehensive  analysis  of  the  Army's  software  problems  was 
prepared,  additional  Information  needed  to  completely  understand 
the  problems  was  identified  and  collected,  and  obstacles  to 


problem 

resolution 

were 

defined 
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a.  Oii-slte  reviews  were  coaducced  co  collecc  additional 
information  needed  for  problem  definition. 

b.  Meetings  were  held  with  industry  consultants  to  compare 
interim  findings  of  Task  Force  with  earlier  findings  of  the 
Software  Engineering  Institute,  the  Army  Science  Board,  and  the 
Defense  Science  Board. 

c.  The  set  of  problems  was  reviewed  with  the  study  sponsor. 

d.  The  problem  definition  was  validated  with  a  Review  Group 
of  Army  software  experts  to  ensure  complete  coverage,  relevance 
of  problems  identified,  and  determination  of  any  initiatives 
underway  which  were  missed  by  the  Task  Force. 

1.3.3  Propoamd  Solutioam. 

An  integrated  course  of  action  to:  develop  a  software  strategy, 
establish  policy  and  process,  integrate  action  across  the  Army, 
and  enforce  software  policy  and  procedure  was  developed.  The 
recommendations  were  separated  into  work  packages  and  roadblocks 
which  prevented  an  earlier  implementation  of  the  recommendations 
were  identified. 

a.  Recommendations  were  prepared  in  four  general  areas: 
strategy,  organization,  controls,  and  resources. 

b.  The  problems  and  proposed  recommendations  were  reviewed 
with  the  study  sponsor,  internal  Army  experts,  and  selected 
industry  consultants. 
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L.J.4  Inpleaeatacloa  MaaageBcnC. 

A  top  level  aianageme.it  plan  was  prepared.  It  will  provide  for 
the  resolution  of  problems  identified  in  the  study  and  better 
management  of  Army  mission  critical  software. 

a.  An  implementation  action  plan  was  prepared  which 
identifies  each  proposed  action  and  lays  cut  a  time  frame  for 
execution  based  on  priority. 

b.  Obstacles  which  prevented  earlier  rcsolucioa  of  the 

problems  were  identified:  statutes,  regulations,  organisational 

impediments,  inertia,  funding,  personnel  capability,  lack  of 
understanding,  or  technology. 

c.  A  transition  ■'Ian  was  prepared  which  provides  a 
management  structure  and  resources  to  ensure  follow>on  efforts 
are  executed. 

1.4  ISSDES 

The  software  Issues,  as  identified  by  review  of  previously 
conducted  software  studies  and  through  a  variety  of  Interviews 
and  discussions,  were  grouped  into  five  general  categories. 
Although  categories  were  used  to  help  clarify  and  classify  the 
issues,  some  Issues  were  difficult  to  classify  because  they  had 
impact  in  multiple  areas.  The  list  presented  below  Is  Che  final 
list  that  was  used  to  derive  the  underlying  problem  areas: 

1.4.1  PEOPLE  -  Software  capability  of  Army  people 

tecrmicmemc  aod  reteeclom  of  software  esperca 

Inadequate  MCDS  SW  Knowledgeable  Workforce 

Failure  to  aaincaln  critical  aass  of  SW  professionals 

Army  has  not  lapleaented  new  Computer  Engineer  series 
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Resourct:  con.itraincs  prevearing  use  of  iaterns /ccGps 
Available  People  Misapplied 
Lack  of  carear  prograa  for  eoftaara  cnglaacra 

No  Developoent  Program  for  Civilian  SW  Professionals 
No  career  path  for  Military  SU  managers 
Lack  of  Installation  Level  SW  Journeyman  Programs 
oov ' c  Personnel  Motivated  Not  to  Tailor  Acquisitions 
Maiatalaiag  state-af-tha-practica  aoftwara  skills 
No  Education  of  PM /Contractor  on  Benefits  of  Ada 
In-House  Skills  don’t  Match  Contractor  Skills 
Difficult  to  get  new  technology  into  SW  centers 
Lack  of  MCDS  SW  Application  Experience 
No  Func t ional / Pr o je c t  SW  Quality  Training  Program 
Lack  of  Interoperability  Expertise 

Area  Support  Analysts  can’t  be  jack-of-ali- trades 
Software  survival  skills  for  aaaagars 

No  Software  Survival  Program  for  GO/SES  Managers 
No  Mid-Level  Software  Awareness  Program 
Outraach  to  paraoanel  affacta4  aoftwara 

No  Prograa  to  Inform  Congress  of  Army  SW  Initiatives 
No  Education  of  ?PBS  Players  of  Importance  of  SW 
No  Software  Ori.'nration  for  HW  people 

Responsibility  fur  SW  Support  Analyst  Training  Unclear 
Responsibility  for  Field  Operator  Training  Unclear 
Revised  Operatoi  Instructions  not  Available  w/  new  SW 

1.4.2  POLICY  **  Ksistcaea  of  a  clear,  eogoot,  affoctlva  policy 

Lack  of  cowaoa  fraaework  for  MCCt  policy 

No  effective  Army  proponent  for  MCCR 
No  MCCR  Planning  Framework 
Mo  MCCR  Guide  for  PMs 

Responsibility  for  Interface  Problems  Undefined 
Responsibility  for  Interoperability  Testing  Unclear 
Responsibility  for  SW  Support  Analyst  Unclear 
Plachora  of  ovarlappiag,  cos^i<cclag  guidaaca 

Army  Po 1 i c y / Re gula 1 1  on s  not  Current  with  DOD  Guidance 
IV &V  Role  of  LCSE  Centers,  QA,  and  TECOM  Confusing 
Confusion  of  Performance  DT  and  IV4V 
Policy  out  of  Cuae  with  caargimg  Caebaology 

Army  does  not  Employ  any  SW  Risk  Management  Approach 
Firmware  given  blanket  treatment  as  software 
Difficult  to  Apply  JOL-STD-2168  to  Ongoing  Work 
OoD  Lata  Rights  Requirements  du  not  motivate  Reuse 
Policy  oadaflaod  or  not  clear 

No  Requirement  for  Use  of  Environment 

Inadequate  DOD-STD-2  1 6 7 /2 168/1467 /1 8 1 5  lapleaentat ion 
No  Approach  Defined  for  Support  of  NDI 
No  Cleat  Interoperability  Test  Policies 
No  clear  definition  of  who  pays  for  interoperability 
No  Higher  Level  Review  to  Insure  proper  SW  $  Support 
Army  has  no  strategy  for  SU  support  in  wartime 
Weak  policy  eoforceaeac,  compllaace  maeawreaeat 

PM/End  Item  Manager  Funding  of  MCDS  Short  of  Requirement 
Poor  Management  Control  to  Ensure  Good  SU  Transitioned 
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Poor  Management  Control  of  Tranfltloned  Documentation 
Mo  feedback,  little  leerolng  from  peat  alatekes 

No  process  to  document  lessons  learned  on  systems 
No  strategy  to  manage  SW  program  and  report  progress 
No  ongoing  review  of  LCS£  functions  and  operations 

1.4.3  PROCESS  -  Software  planalog,  budgeting,  and  coat  concrol 

No  effective  coaputer  reaource  aaaagea*nt 

Status  of  CRMPs  far  Army’s  200  MCDS  Undefined 
CRMPs  not  ^e  pared  Early  Eno..gh  to  have  Impact 
JRMPs  Inadequately  Prepared 

No  data  base  exists  whlcn  Identifies  computer  resources 
CRMPs  not  Reviewed  by  CRWG 

No  use  of  CRMPs  to  Control  Acquisition  Plan  Approval 
CRMPs  not  Submitted  to  AMC  for  Approval 

Vagua,  lll-deflaed,  or  undeflnabla  raqulraaaata 

Poor  Feedback  between  Requirements  and  Specifications 
Insufficient  1 ime / r e s ou r c e s  to  Develop  SU  Specs 
Little  iraallaa  In  coat  eatlaatca  for  aoftwara 
No  Accepted  SW  Resource  Esc! aa tors 

Management  Documenc  Keq  u '  remcnf;  u  Waived  to  save  Tlaa/$ 

Poor  Mechanism  to  Evaluate  MCDS  Change  on  Intaroparabillty 
Poor  Mechanism  to  Evaluation  Inceroparablllty  Chang*  on  HCDS 
laaffaeclea  ’'radaoff  of  raqulraaaata  varsua  coat 
Inadequate  I i me / Re s ou r c e a  for  SW  Davelopatat 
Poor  uadarataadiag  of  trua  aoftvara  support  coat 

No  Iden 1 1 f 1 ca *  Ion / Ju s 1 1 f 1 cd c ion  of  Resources  In  CRMPs 
Corractioa,  anhaacaaant,  and  aodificatioa  coatrol 
MCDS  Software  Changes  not  Tlaely 
SW  Changes  required  to  Fit  Into  PIP  Process 
•adgat  process  uaraepoaslvo  to  aoode 

No  Methodology  ro  Prlorlrizc  SW  Support  Workload 
Difficult  to  address  multi-year  funding  of  SU  Support 
Rasourca  Requirements  Inadequate  to  Support  SU  aaintananca 
Inadequate  Software  Technology  Funding 
Duplicatloa  of  aofevara  f aactioaa/facllltloa 

No  Documented  Plan  (S-yr)  for  LCSE  Cancer  Improvement 
Support  for  Training  Device  SW  aay  require  new  LCSE 
Duplication  of  resources  at  co-located  LCSE  Cencare 

1.4.4  PtOCIOOllS  -  Coatrol  of  aoftwara  acquislCioa/sappott 

■o  ovarall  aaaagaacnt  aad  control  of  aoftvara 

HQ, AMC  has  abdicated  its  MCDS  software  aanageaent  rola 
Perceived  Overlap  of  SW  Effort  by  Functional  Eleaante 
No  Differentiation  of  Manageaent  for  Typta  of  SW 
Management  process  aimed  at  eliainating  judgaecc 
No  Maatar  Plan  for  SW  Comaonsllty  across  MCDS 
Poor  Profit  Margins  for  Army  Custom  SW 
SW  Warranties  not  used  for  Stabilized  Common  SW 
Modification  of  NDI  SW  not  Addreeeed 
Materiel  Release  program  oriented  to  HU  not  SU 
SW  contracts  lot  tied  to  contractor  capability  maasirse 
Llttla  tuldaaca  for  solactloo  of  aoftvara  eawlromaaata 
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No  Standard  SW  Development  Environment 
No  Standard  SW  Support  Environment 
No  Standard  SW  Test  Environment 
L»tk  of  def inltloa/lntegrmtlon  of  softwAre  tools 
roll  fetation  of  Test  Tools 
i.nac>quace  S  Im  al  a  t  o  r  s  /  Te  s  C  Bed  Standardization 
Lack  of  S t and  I  r d 1 z ed  SW  CM  Tools 
Software  Tool  usage  still  In  infancy 
Lack  of  aaaageaeac  of  developaoaC  and  aethodologies 
.Lack  of  L'sa'.le  SW  Design  Documentation 
DOD-STD-2I6>A  Still  ^p  ha  sizes  waterfall 
Each  SW  Prorurement  Package  Must  “ S tar t- f rom-Sc r a tc h" 
No  Definition  cl  Standard  SW  Documentation  for  NDI 
No  Standard  way  to  measure  goodness  of  designs 
No  SW  Standardized  Transition  Plans 

No  Standard  Approach  to  Evaluate  Non-Ada  MCDS  Design 
No  SW  Coding  Standards  for  Non-Ada  MCDS 
No  SW  Testing  Standards  for  Non-Ada  MCDS 
Inadequate  SW  Docuusntaclon 
Ineffective  monitoring  of  Design  Process 
Traoaltlon  to  the  use  cf  Ada 

Poor  Support  for  Ada  Introduction 

No  Standardizaclon/Control  of  Ada  SW  Requirements 
No  Master  Plan  to  Upgrade  Existing  SW/Retroilt  to  Ada 
No  Up-co-Date  Ada  Introductlon/Hanagement  Plan 
lateroperabllity  of  ayateas,  HV/SU  integration 
MCDS  Interoperability  Requirements  Unclear 
Historical  lack  of  standardization  of  MCDS  Data  Llnka 
Inadequate  Test/Interf ace  Criteria  for  SW  Modules 
Lack  of  Common  Embedded  Processors 
Lack  of  Common  Test  Equipment 
Lack  of  Common  Program  Media 
Lack  of  Common  Media  Replication  Equipment 
Lack  of  Common  Support  Computers/Envlronment 
Lack  of  Common  T.ipe  Loading  Units 
Lack  of  Common  Disk  Units 

Lack  of  Common  Communications  Interface  Processor 
Enforcement  of  configuration  control 

Approved  MCDS  Software  Baseline  not  Adhered  to 
No  Standardization  of  SW  CM  Planning 
Inadequate  tracing  of  Detailed  Design  from  Specs 
Inadequate  Local  Auditing  Procedures 
Lack  of  Standardized  CM  System/ Procedures 
Contractor's  non-dellverable  SW  uncontrolled 
No  CM  Status  Accounting  Requirements 
Inadequate  SW  Configuration/Change  Control 
Lack  of  SW  Configuration  Control  Boards 
Inadequate  SW  Configuration  Audlts/Revlews 
Lack  of  Standardized  CM  Documentation 
No  plan  to  transition  CM  data  base  from  contractors 
Software  Quality  Assuraoco 

SQA  standards  not  consistently  invoked 
Inconsistent  approach  to  SQA  in  LCSEs 
Bf fectlvameas  of  Casting  and  IVA? 

No  Design  Techniques /Methodology  for  Test  Tool  ID 


MCDS  Testing  not  Centrally  Coordinated 
Lack  of  Simulators  and  Stimulators  during  Development 
Inadequate  Review  of  Test  P r oc edu r e s / Re sul t s 
•  Inadequate  Comp r e he n s 1 ve / D 1  sc  1  p  1 1 ned  Test  Practices 
Failure  to  Define  Quantitative  Acceptance  Tests 
Inadequate  Re  sour c e s / P r oc edur e s  for  Test  Integration 
Poor  Coordination  of  Sys tem/ Inter-System  Test  Programs 
Deferment  of  L'nlt  Level  Testing  Until  Systems  Test 
Interoperability  Test  Concepts  Unclear 
Interoperability  Test  Plans/Prccedures  Unclear 
No  Interoperability  Test  Bed  for  De ve lopment /Supper t 
Lack  of  Interoperability  Testing  during  Development^ 
Software  rapllcatfoa,  dlstributioo,  amd  cootrol 

Unworkable  SW  Re p 1 1 c a t ion/ Dup I Ic a t ion / Ins t a  11a t Ion 
Army  Supply  System  Unresponsive  to  SU  Distribution 
Untimely  Field  Repla;ement  of  Fai led/ Superseded  SW 
Untimely  Distribution  of  New  SW  Documentation/Training 
No  provision  to  electronically  transmit  changes/ updates 
Inefficient  use  of  Personnel  to  Support  SW  Distribution 
Intatratloa  of  Life  Cycle  Software  Camtara 
Cloawra  of  faadback  loop  with  field 

AMC  Support  to  Field  seen  as  Unresponsive 
No  Standards  for  Processing  Field  Users  Trouble  Reports 
Uneven  Technical  Support  to  Field  from  LCSEs 
No  Slngle-face-to-f icld  for  SW  Problems 

1.4.S  PLAMNIVC  Support  for  research  amd  ceehoology  imee 

Overall  plan  for  Aray  SH  Techmology  Efforts 

Strategy  not  built  on  leveraging  off  private  sector 
STARS  Program  not  Apropos  to  Army  Needs 
No  advocate  for  software  technology  in  Army 
lasertioa  of  mew  techmology  into  eyatems 

Army  State-of-Practlce  far  Behind  S tate-of-Ar t 
No  Support  for  Technology  Insertion 
Lack  of  Army-wide  Software  Technology  Center 
Oeflmiclom  of  integrated  eoftware  eeviromaemt 

Inadequate  Strategy  to  Use  Commercial  SW  Tools 
No  Definition  of  Minimum  Toolsets 

No  standards  for  interchange  of  data  from  tools  exists 
Lack  of  Facilities  for  Rapid  Prototyping 
Ada  inefficiency,  lack  of  run  time  environment 
Ada  Benefits/Problems/ Issues  Undefined 
No  plan  to  address  Ada/Non-Ada  Integration 
No  Performance  Tests  for  Ada  Compilers 
No  automated  process  for  requirements  definition 

Loss  of  Traceability  from  Specifications  to  Design 
Software  component  definition,  reusable  software 
No  Plan  to  Reuse  SW  In  Army's  MCDS 
Lack  of  progress  In  establishing  basis  for  reuse 
Lack  of  OTS/COTS  Ada-based  SW  to  serve  as  reuse  base 
No  Program  to  Identify  Common  SW  Modules 
No  Plan  to  Develop  OS/Appllcat Ion/ support  SW  Library 
No  Methodology  to  Manage  Reusable  SW  Components 
No  Methodology  for  Configuration  Control  of  Modules 


Lack  of  Reusable  SW  Modules 
Lack  of  Rehostable  SW 
Lack  of  Recargecable  SW 
Lack  of  Common  SW 

No  Incentives  for  Contractors  to  develop  Reusable  SW 

High  reliability/ locegrlty  aoftware  deeelopacat 

No  guidelines  for  test  driver  certification 
Ose  of  distributed  systema  amd  parallel  proceaalog 

No  guidelines  for  modeling  and  simulation 


SBCTIOM  II 
Prob J  eas 


"as  long  as  there  were  no  machines,  programming  was  no  problem  at 
all;  when  we  had  a  few  weak,  computers,  programalng  became  a  mild 
problem  and  now  that  we  have  gigantic  computers,  programming  has 
become  an  equally  gigantic  problem.  In  this  sense  Che  electronic 
industry  has  not  solved  a  single  problem,  it  has  only  created 
them  -  it  has  created  the  problem  of  using  its  product". 

"The  Humble  Programmer" 

E.  U.  Dijkscra 

Turing  Award  Lecture,  1972 


2.1  CHALLENGE  TO  THE  AHMT. 

Computer  software  plays  a  critical  role  In  Army  mission  critical 
defense  systems.  DoO  Congressional  testimony  has  described 
software  as  follows; 

"Software  is  the  human  intelligence  tnat  is  programmed 
into  our  systems.  It  allows  advanced  sensors  to 
discriminate  and  track,  navigation  systems  to  follow 
prescribed  routes,  guidance  systems  to  control 
trajectories,  and  communications  systems  to  properly 
route  thousands  of  messages.  Software  keeps  track  of 
the  status  of  our  forces,  maintains  intelligence 
Information  on  enemy  forces,  and  aids  our  commanders  in 
deciding  on  target  actions." 

As  the  complexity  of  Army  defense  systems  increases,  mission 
crlticel  software  seems  to  be  getting  out  of  control.  Software 
is  the  leest  understood  and  has  the  highest  perceived  risk  of  eny 
aspect  of  systems  development.  It  contributes  an  ever  increasing 
share  of  acquisition  risk  and  its  aggregate  cost  grows 
exponentially.  However,  software  offers  the  only  hope  for 
meeting  today's  requirements  for  battlefield  command  and  control, 
and  weapons  system  operation. 


The  capability  and  technology  of  Army  software  will  determine  who 
dominates  the  battlefield  of  the  1990's  and  beyond.  It  is  the 
embedded  computer  with  its  requisite  software  which  permits 
battlefield  commanders  to  operate  within  the  enemy's  decision 
cycle.  Software  allows  the  Army  to  meet  rapidly  changing 
threats,  incorporate  sophisticated  controls,  and  assist  the 
commander  in  the  conduct  of  his  mission.  The  challenge  to  the 
Army  is  to  effectively  manage  software  and  Its  technology  so  Army 
needs  are  met  at  minimum  life  cycle  cost.  The  Army  must  bring 
Che  cose  of  Its  software  under  control,  guarantee  high  quality  in 
Its  software  products,  and  malntaio  technological  superiority  of 
Its  software  driven  systems. 

2.1.1  Cose  of  Sofevarc. 

The  amount  of  money  spent  on  computer  software  has  been  growing 
at  an  exponential  race.  It  has  been  estimated  chat  Che  annual 
cost  of  computer  software  and  services  for  the  Department  of 
Defense  will  Increase  from  311.4  billion  in  FY-8S  to  336  billion 
in  FY-9S.  If  current  trends  continue,  computer  software  costs 
could  exceed  the  entire  defense  budget  by  the  year  2015.  Whether 
this  prediction  is  to  be  believed  or  not  is  immaterial.  There 
are  numerous  dire  predictions  of  software  cost  and  complexity 
growth.  Many  of  these  predictions  point  to  the  high  level  of 
costs  required  to  maintain  software  systems  after  deployment. 
Currently,  between  50  and  75  percent  of  the  software  cost  for 
Army  weapon  systems  is  expended  for  post  deployment  support, 
commonly  known  as  software  maintenance. 
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The  Army  firsc  approved  ics  coacepC  for  Pose  Deployoenc  Software 
Support  (PDSS)  In  1978.  Each  year  since  then,  resource 
requirements  for  software  support  have  far  exceeded  the  amount 
funded.  Yet  no  impact  of  this  lack  of  funding  was  evident.  In 
some  cases  the  requirements  were  overstated  because  they  were 
based  on  inadequate  cost  prediction  methods.  This  overstatement 
continues  to  hurt  the  credibility  of  the  Army  software  community. 
In  other  cases,  inadequate  funding  led  to  Che  deferral  of 
important  software  corrections  and  enhancements.  The  most 
insidious  effect  of  this  funding  profile,  however,  has  been  the 
deferral  of  software  engineering  considerations  during  system 
development.  Poorly  designed  and  inadequately  documented 
software  has  been  delivered  to  and  accepted  by  the  Army.  These 
deficiencies  have  increased  the  level  of  effort  needed  to  sustain 
the  systems  until  the  software  could  be  reverse  engineered  and 
matured.  In  some  cases  the  Initial  cost  of  sustaining  software 
is  more  than  double  the  cost  reached  at  maturity.  Each  year  the 
consequences  of  these  deferments  have  been  compounded.  The  Army 
is  now  faced  with  a  large  software  support  liability.  In  FY~89, 
the  Army  must  either  find  additional  funds  to  sustain  existing 
fielded  systems  or  drop  software  support  for  some  of  those 
systems.  The  situation  will  only  get  worse  as  additional 
software  intensive  systems  continue  to  be  fielded. 

2.1.2  Product  and  Process  Control. 

As  Army  systems  come  to  increase  their  reliance  on  embedded 
computers,  software  complexity  increases  and  ics  critical  impact 
grows.  Software,  in  fact,  is  necessary  to  implement  all  of  the 


Army's  current  Command  and  Control  Initiatives*  Thus,  Che 
responsiveness  and  reliability  of  our  defense  systems  is  software 
dependent.  The  challenge  to  the  Army  is  to  ensure  embedded 
software  is  planned,  developed,  acquired,  integrated,  tested, 
fielded,  and  supported  so  the  Army  can  meet  its  battlefield 
objectives.  For  this  to  happen  Che  software  must  b*e  available  on 
a  timely  basis  and  meet  quality  and  performance  requirements. 

A  direct  result  of  the  order  of  magnitude  growth  per  decade  in 
the  requirements  for  software  has  been  a  growing  shortage  in  the 
number  of  qualified  software  engineers.  The  need  for  software 

engineers  has  grown  at  a  rate  of  approximately  12Z  per  year 
during  Che  80' s.  This  has  resulted  in  a  shortage  of  qualified 
people  since  Che  increase  in  new  practitioners  has  been  only  4-6Z 
per  year.  For  a  variety  of  reasons  discussed  later,  the 

situation  within  Che  Army  is  even  worse.  It  is  critical  for  the 

Army  to  find  a  means  of  increasing  the  productivity  of  its 
software  development  and  support  activities  and  to  more 
efficiently  use  the  people  which  are  available. 

Some  believe  significant  increases  in  software  productivity  can 
be  achieved  solely  through  the  introduction  of  the  latest 
technology.  This,  however,  is  a  misconception.  An  effective 
approach  for  software  productivity  involves  much  more  than  the 
introduction  of  "modern  programming  practices.'*  For  example, 
experience  with  a  computer  language  or  in  an  application  area, 
the  use  of  powerful  software  tools  or  modern  programming 
practices,  and  the  effect  of  introducing  stringent  design  goals 

for  reliability  provide  only  a  minimal  productivity  improvement 
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when  considered  individually.  P r o d u c c  i  v 1 c y  enhancing 
opportunities  must  be  sought  and  management  actions  taken 
throughout  the  entire  software  life  cycle  if  the  software  process 
and  its  products  are  to  be  brought  under  control. 

2.1.3  Techaologicai  Advantage. 

It  can  be  argued  that  America's  greatest  mllicary  strength  lies 
in  the  individual  initiative  and  Ingenuity  of  our  Service  people. 
The  fruits  of  their  initiative  and  Ingenuity  are  bolstered  by  the 
technological  superiority  of  our  defense  systems.  This  need  for 
technological  superiority  makes  computer  technology  especially 
critical.  Because  Army  conventional  forces  are  outnumbered  in 
almost  all  areas  on  the  battlefield,  they  rely  on  mission 
critical  computer  systems  to  serve  as  a  force  multiplier. 
Software  based  command  and  control  systems  help  to  provide  the 
knowledge  base  which  fosters  initiative  in  battle  plannitg.  They 
allow  a  more  effective  deployment  of  Army  troops.  Embedded 
computers  operating  In  real-time  can  and  do  dramatically  increase 
the  lethality  of  the  weapons  into  which  they  are  incorporated. 
The  relative  ease  of  adapting  software  provides  the  ability  to 
introduce  enhancements  more  quickly  and  at  less  cost  than  making 
hardware  changes.  Software  can  extend  the  useful  life  of  a 
system  by  Incorporating  Incremental  improvements  and  quickly 
responding  to  changed  threats.  In  some  cases  software  has  been 
used  to  overcome  defects  in  original  hardware  design.  Most 
Important  of  all,  however,  is  the  advantage  the  U.S.  holds  in  the 
area  of  software  development.  Because  the  American  technological 
lead  has  been  shrinking  In  other  areas,  it  is  essential  to 
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maintain  and  increase  the  ability  to  capitalize  on  software 
technology. 

Fortunately,  maintaining  a  software  technology  advantage  does  not 
require  huge  expenditures  of  Army  research  and  development  funds. 
The  pervasive  use  of  the  microcomputer  and  the  development  of  a 
mass  market  for  software  technology  has  spurred  the  development 
of  the  industrial  base  for  software  technology.  The  challenges 
to  Che  Army,  therefore,  are  not  so  much  technical  as  they  are 
managerial.  A  strategy  to  capitalize  on  and  use  advances  made  by 
industry  is  desperately  needed.  The  Army  cannot  let  its  software 
advantage  slip  away;  instead  it  needs  to  manage  and  effectively 
insert  new  technology  to  increase  its  advantage. 

2.2  TAXOHOMY  Of  PtOBLEMS. 

The  Task  Force  felt  the  Army  must  abandon  any  search  for  a  magic 
potion  to  bring  about  a  marked  reduction  in  the  cost  of  software. 
Improvement  of  produce  and  product  control,  and  maintenance  of 
technological  superiority.  Such  a  tool  or  technique  does  not  • 
exist.  In  actuality,  a  variety  of  institutional,  political,  and 
socioeconomic  problems  must  be  addressed  before  the  Army  can 
improve  its  control  and  management  of  software.  Instead,  the 

Army  must  emphasize  sound  management  practices  and  the  selected 
use  of  new  technologies  as  their  worth  is  proven.  Decisive  and 
coordinated  actions  need  to  be  taken  to  improve  the  software 
capability  of  Army  people,  establish  a  clear  and  cogent  software 
policy,  develop  better  controls  and  procedures  to  control 
software  acquisition  and  support,  and  plan  for  capitalization  and 
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insertion  of  appropriate  software  technology  into  Che  way  the 
Command  does  business.  A  unified  productivity  loprovement 
program  needs  to  be  initlatea.  The  formula  for  success  Is  very 
simple: 


PRODCCT  IV  ITY 


PEOPLE  IMPROVEMENT  and 
POLICY  IMPROVEMENT  and 
PROCESS  IMPROVEMENT  and 
PROCEDLRE  IMPROVEMENT  and 
PLANNING  IMPROVEMENT 


Note  that  productivity  is  more  chan  Che  sum  of  improvemencs  made 
In  five  specific  problem  areas.  It  is  cheir  logical  conjunction. 
Failure  to  se  :  gains  in  any  one  of  the  areas  can  obvlace 
improvemencs  made  in  Che  ocher  four.  For  example,  che  clearest 
policy,  Che  besc  procedures,  and  che  most  up-co-dace  cools  can  be 
undone  If  Che  workforce  is  untrained  or  unmotlvaced.  A  taxonomy 
was  developed  and  used  Co  classify  che  problems  InCo  Che  five 
areas  essential  for  real  producclvlcy  improvement  and  Chen 
according  co  twenty  three  observable  effects.  Figure  2.1 
Illustrates  che  taxonomy  scruccure.  The  causes  shown  on  che 
diagram  correspond  closely  with  che  Issues  Identified  in  Section 
I  of  this  report.  Eighty  five  problems  were  Identified.  Their 
taxonomy  and  a  descripcion  of  each  is  contained  In  Appendix  A, 
but  summary  of  each  of  che  problem  areas,  cheir  effects,  and  a 
pointer  che  examples  in  Appendix  A  Is  presented  below. 

2.2.1  People. 

People  efforts  need  co  focus  on  building  a  new  sofcware  cadre 
while  addressing  che  existing  work  force  both  military  and 
civilian.  Action  must  be  taken  co  establish  sofcware  engineering 
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AREA 


EFFECT 


PROBLEM 


CAUSE 


Rgura  2.1  -  Soflwar*  ProblMi  Tneaoaqf 


as  critically  loporcant  and  strongly  supported  throughout  the 
Army.  Programs  to  develop  software  Intern^,  provide  career  paths 
for  careerists,  train  managers  with  appropriate  software 
management  skills,  and  satisfy  continuing  education  requirements 
must  be  pursued.  The  following  specific  problems  ought  to  be 
attacked: 

Little  awareness  of  Software  Criticality  to  the  Army  (Al'AS) 
Difficulty  In  Recruiting  Software  Talent  (A6-A10} 

Mid  Career  loss  of  Software  Talent  (A11-A13) 

Inadequate  Software  Training  Program  (A14'>A18) 

Inadequate  Software  Education  Program  (A19~A2I) 

2.2.2  Policy 

Numerous  regulations,  pamphlets,  letters,  and  guidebooks  exist 
which  are  supposed  to  guide  the  project  manager  In  the 
acquisition  of  computer  hardware  and  software  In  the  Information 
Mission  Area.  In  general,  however.  Project  Managers  are  not 

Problmmm 
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aware  of  what  is  required  or  where  to  go  for  help.  The  policy 
needs  to  be  sec  in  a  common  framework.  Because  the  Army  cannot 
arford  to  be  locked  out  of  the  mainstream  of  software  technology, 
provisions  need  to  be  made  to  keep  the  policy  in  tune  with 
emerging  technology  ano  practice.  The  policy,  however,  must 
remain  consistent  over  time  and  ^  mechanism  must  be  put  in  place 
to  enforce  software  policy,  measure  compliance,  and  develop 
lessons  learned  so  we  can  learn  from  cur  mistakes.  The  solutions 
to  problems  in  four  specific  areas  need  to  be  found: 

Software  treated  as  if  It  were  monolithic  (A22-A2A) 

Caps  and  Inconsistencies  in  Software  Policy  (A2S-A27} 

No  Evaluation  of  Software  Policy  Effectiveness  (a28*'A30) 
Little  Policy  Evolution  for  Emergent  Methods  (A31~a33) 

2.2.3  Process. 

Processes  for  software  planning,  budgeting,  and  cost  control  are 
out  of  control.  Controls  need  to  be  established  to  effectively 


manage 

the 

acquisition  of 

computer  resources 

and 

to  provide 

realism 

in 

cost  estimating. 

Key  problem  areas 

for 

resolution 

Include : 

System  Requirements  poorly  defined  and  executed  (A34-A37) 
Ineffective  Computer  Resource  Management  (A38-AA0} 

Funding  Inadequate  for  Software  Support  (A41-AAS} 
Responsibilities  for  Software  Unclear  (A46-A49} 
Ineffective  Software  Management  Process  (AS0-AS3) 


2.2.4  Proesdurms. 
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Procedures  which  impacc  Army  systems  have  received  inadequate 
consideration.  Efforts  must  be  mounted  to  address  earlier  and 
more  fruitful  interaction  with  the  user,  a  cleaner  handoff  to 
contractors  where  appropriate,  and  methods  to  enhance  the 
maintenance  process  done  in-house.  Procedural  improvements  in  at 
least  the  following  six  areas  ought  to  be  pursued: 

Inadequate  Software  Management  Process  (A54-A57) 

I’nco  n  s  t  r  a  i  ned  Software  Environment  (A58-A61) 

Lack  of  Enforceable  Standards  (A62-A6S) 

Need  to  account  for  Ha rd wa re / So f twa re  Differences  (A66-A69) 
Lack  of  coordination  across  matrix  Organizations  (a70’-a71) 
Untimely  response  to  field  software  Problems  (A72-A75) 

2.2.5  Planaloc. 

A  Strategy  for  the  investigation  and  eventual  Insertion  of  new 
software  technology  must  be  developed.  Candidate  Items  ought  to 
include  methods  for  realistic  software  resourcing,  methodologies 
to  permit  more  effective  maintenance  of  software  once  delivered, 
and  a  mechanism  for  testing  and  inserting  new  software  tools  as 
appropriate.  Key  deficiency  areas  Include: 

Army  has  no  defined  software  technology  strategy  (a76-*a79) 
Failure  to  capitalize  on  software  advances  (A80-A83) 
Technology  Insertion  measures  ineffective  (A84-’A8S} 
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SBCTIOI  III 
tcconocadat loas 

"Perhaps  the  otosc  important  principle  on  which  Che  economy  of  a 
manufacture  depends.  Is  the  division  of  labour  amongst  Che  persons 
who  perform  the  work.  The  division  of  Labour  suggests  Che 
copcrlvancc  of  cools  and  machinery  to  execute  Ice  processes'*. 

"On  the  Division  of  Labour" 

Charles  Babbage,  1832 

3.1  TACIMG  TBI  IBlTlATIfl. 

Army  software  Initiatives  have  been  the  direct  result  cf  a 
variety  of  panels  and  groups  which  have  examined  the  aofeware 
problem  for  the  DoD  and  the  Army.  in  the  mld'-ZO'c  the  DoD 
Software  Management  Steering  Commlccas  recognised  the  problems 
Inherent  In  a  wide  diversity  of  programming  laaguagas  and,  as  a 
result,  Inlclatsd  work  on  a  language  which  was  later  named  Ada. 

as 

The  Computer  Resource  Management  Joint  Policy  Coordinating  Group 
of  the  Joint  Logistics  Conmsndcrs  sponsorsd  chs  Montarsy  I  A  II 
workshops  with  industry  which  Idtnclflsd  chs  nssd  for  common 
sofewsrs  stsndsrds  and  chs  Orlsndo  I  4  II  workshops  which 
addrssssd  Ilfs  cycls  sofewsrs  support  Issusa.  Tho  Army  conductsd 
a  study  of  chs  way  It  supportsd  smbsddad  softwarm  which  lad  to 
the  Post  Dsploymsnt  Sofewsrs  Support  conctpc  In  chs  lata  70's  and 
the  Army  Sclancs  Board  suggaacad  the  need  to  address  software 
during  Che  anclrs  lift  cycle  which  lad  to  the  Lite  Cycle  Software 
Englnaarlng  program.  The  primary  facilitator  amd  isplamancor  of 
Chaif  )  Inltlativaa  within  the  Army  has  bean  AMC.  Thmam  and  ocher 
ir<claclvaa  have  anablcd  the  Army  to  make  real  progress  in 
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addressing  problems  in  software  productivity,  management,  and 
quality.  Now,  however,  momentum  has  been  lost.  AMC  Headquarters 
has  abdicated  Its  role  In  the  management  of  Hlssi  n  Critical 
software.  This  study  recommends  an  Integrated  course  of  action 
to  cry  to  gain  control  of  the  software  In  the  Army's  syscams.  As 
Figure  3.1  lllu|craces,  Che  recommendations  have  bean  grouped 
Into  four  large  work  packages.  Briefly,  the  recommendacions , 
which  are  listed  In  Appendix  B,  call  for  the  Army  to: 

a.  develop  a  strategy  for  HCCR  Acquisition, 

b.  organize  to  manage  the  acquisition  and  support  of 
software  Incanrlve  systems, 

c.  establish  controls  to  guide  programs  and  manage  system 
acquisitions,  and 

d.  allocate  sufficient  resources  for  mission  critical 
computer  resources. 

3*1.1  Dawmlop  a  Strategy* 

As  shown  in  Figure  3.2,  the  racoaaandations  for  developing  an 
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Software  Technology  Plan 

Concept  tor  Software  Reuse 
Developnr>ent/Use  of  Metrics 

Life  Cycle  Model  Evaluation 

— 

TECHNOLOGY  APPUCAT10N 

Use  of  Software  Environments 

Ada  Introduction 

Reverse  Engineering 

ACQUISmON 

Integrated  Sof^A>‘are  Planning 
TailSred  Acquisition  Proo^ 
Consistent  AoquisltiQn  Conoe^ 

ovcr«ll  icracviy  for  MCCR  acqulslcioat  art  sub-dlyMad  into  chr«« 
smallar  packagaa.  Tha  flrat  calls  for  building  a  acracagy  to 
conduct  rasaarch  In  cKa  araa  of  software  anglnaarlng  basad  on 
gatting  the  aaxlsiua  leverage  off  advances  aada  by  industry.  The 
second  part  of  tha  stratagy  should  identify  ways  in  which  the 
Arny  can  apply  at  least  stata-of-tha-practica  technologiaa  to  ita 
systaaa.  Finally,  tha  Aray  auat  look  at  ita  acquisition  process 
to  provide  for  technology  insertion. 

3.1.2  Orgaalsa  to  Maaato. 

Figure  3.3  shows  three  aspects  of  the  Aray  organisational 


atructure  which  auat  be  iaproved  in  order  to  better  aanag 
toaort  of  tbe  AMC  Software  Task  Voree  ee 


alsflon  critical  software.  First  of  all,  orgaoisatlonal  aissioas 
and  roles  in  the  area  of  aission  critical  software  need  to  be 
clarified  and  streaalined.  Second,  our  executing  coaaands  and 
their  software  centers  need  tighter  controls  and  bette 
interfaces.  Finally,  and  perhaps  aost  critical,  the  Aray  needs 
to  develop  advocates  who  understand  the  critical  role  of  software 
in  today's  Aray  and  can  effectively  fight  for  the  resources  Che 
Aray  aust  invest  in  this  area. 


3.1.3  gstabllsh  bactar  Coaerola. 

Figure  3.4  identifies  Che  two  asln  types  of  recoaasodac Ions 
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Acquisition  Policy 
Funding  Policy 
Softwafe  Change  Process 
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SYSTEM  MANAGEMENT 
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Software  Maturity  Management 
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coac«ra«d  vlcb  ch«  «tc«bli«hB*ac  of  sort  cffoctiv*  coaerols  for 


■Istioa  crlclcal  coaputtr  tysctas.  Tha  firtc  group  of 


rtcoaaandacioos  la  focuaed  oa  choaa  aapacca  of  policy  and 


anforcaaanc  aactaaary  co  aora  affacclvtly  provlda  dlraccloa  to 


acqulalcloo  prograaa.  Tba  aacood  group  of  racoaaandacloaa  Is 


dlractad  ac  tba  caaka  wblcb  auac  bo  parforaod  la  carcala  kay 


f unc  c lonal 


3.1.4  laaoarca  AllocaCloa. 


Thara  ara  cbraa  aapacta  of  raaourca  allocacloa  vhlch  auac  ba 


addraaaad.  Aa  abown  la  Flgura  3.5,  proeoaaaa  to  Idaaclfy  and 


allocaca  aufflclanc  fuadlag  for  aoftwara  acdvlclaa  aaad  co  ba 


laplaaancad,  aaaaa  co  baccar  allocaca  In-bouaa  paopla  ao  ebay  ara 
noc  aaraly  coocracc  aoalcora  auac  bo  found,  and  acapa  co  baccar 
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FUNDING 

Software  Cost  Models 

Track  Budgetin^Aliocation 
identify/Capture  Actual  Cost 

RESOURCE  ALLOCATION 

Front  End  Load  LCSEC  Role 
Altenw^e  Support  Options 
Contractlfig  OutStudy 

Measure  Enidency 

FEOFiE 

ClyJ!!®"  ¥®npow€r  strategy 

MIIHary  Softie  ExpSte'^^ 

Career  Managernerrl 

Hpwt.<  -  AiBCiii  far  Meal 


train  and  devalop  In-houaa  paopla  aunt  ba  cakan. 


SECTIOI  I? 
lapleaentatloa 

“If  It  were  done,  when  'tis  done,  then  'twere  well  It  were  done 
quickly" . 

“Macbeth" 

Wllliaa  Shakespeare 


4.1  MO  MOIB  BAND  AIDS. 

There  Is  no  need  to  continue  to  study  and  restudy  Che  software 
problems  with  mission  critical  computers.  Over  the  past  several 
years,  problems  with  the  Army's  software  engineering  process  have 
been  documented  in  a  variety  of  concept  plans,  workshops,  reports 
and  studies.  This  report  has  attempted  to  provide  a  unified  view 
of  Che  issues,  problems,  and  their  recommendations.  The  issues 
are  clear.  Ac  integrated  sec  of  problems  has  been  defined.  Now 
resources  must  be  found  to  address  the  recommendations  in  a 
focused  effort.  If  the  recommended  actions  are  to  be  addressed, 
Che  Army  can't  depend  on  ad  hoc,  one-time  projects.  An  orderly, 
task-oriented  approach  needs  to  be  followed  using  dedicated  in- 
house  expertise,  contract  support  as  needed,  and  the  cooperation 
and  support  of  industry. 

4.1.1  Plammluf  Templaces. 

The  Task  Croup  analysed  and  prioritised  each  of  its 
recommendations.  The  results  of  that  effort  are  contained  in 
Appendix  C  to  this  report.  Roadblocks  which  prevented  earll'-r 
efforts  in  these  areas  have  been  identified.  It  is  algnifieanc 
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to  note  that  only  one  recommendation,  getting  pay  comparability 
with  industry,  requires  statutory  action.  Many  require 
regulatory  or  organizational  changes,  but  an  even  larger  number 
haven't  been  accomplished  just  because  of  inertia  --  no  one 
tried.  There  are  also  a  large  number  of  recommendations  which 
need  a  significant  amount  of  resources  in  order  to  be  completed. 
Resources,  in  this  context,  could  include:  (1)  funds,  (2) 
technically  qualified  people,  (3)  reaching  an  understanding  of 
new  concepts,  or  (4)  development  of  new  technology.  An 
approximate  schedule  showing  when  each  of  the  recommendations 
could  be  addressed  was  also  prepared.  The  scheduling  reflects 
the  Task  Force's  perception  of  the  priority  of  the 
recommendations  and  implies  a  sequencing  of  tne  casks.  It  it  not 
based  upon  a  detailed  analysis  of  resource  rcquirementa  and 
availability,  so  therefore  the  times  should  be  viewed  only  as  a 
first  cut  approximation  at  this  time. 

4.1.2  Omtallmd  Plaaming. 

The  first  step  in  the  i  mp  1  e  me  n  c  a  c  i  o  n  of  the  Task  Force 
recommendations  must  be  the  development  of  a  detailed  plan  far 
Che  execution  of  each  cask  shown  in  Appendix  R  and  the  subsequent 
updating  of  the  information  in  Appendix  C.  The  plan  for  each 
cask  ought  to  include  the  following: 

a.  Organization  responsible  for  completion  of  the  task  and 
organizations  which  will  provide  support 

b.  Events  which  must  be  completed  before  a  task  is 
initiated,  and  tasks  which  are  predecessors  to  it 

c.  Subtasks  which  comprise  the  task 
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d.  Resources  (time,  money,  people,  and  equipment)  required 
to  complete  the  task 

e.  Measures  of  success  which  will  be  used  to  determine  when 
the  cask  Is  completed 

4.1.3  High  Priority  Tasks. 

There  are  certain  nigh  priority  casks  which  will  drive  many  of 
Che  actions  taken  in  Implementing  this  study.  Efforts  on  them 
should  be  initiated  In  parallel  with  the  detailed  planning 
process.  Those  casks  are: 

a.  SS'‘211A  Reorganize  UQDA  acquisition  mansgemanC 

b.  SS-213  Clarify  Organizational  Rasponalbllltiaa 

c.  SS-132A  Define  a  streamlined  CRMP  process 

d.  SS~31Sa  Develop  e  datebaee  with  MCCt  iaformaclon 

e.  SS*411A  Mendece  tbs  use  of  SECOMO  for  POSS  efforts 

f.  SS-312A  Define  BPRR/MAMP  manpower  process 

g.  SS~323B  Accelerate  funding  of  AIN 

h.  SS-134C  Evaluate  and  use  contractor  performance  info 

i.  SS'321A  Provide  for  Total  Quality  Management 

J.  SS'lllA  Create  software  technology  plan 

k.  SS'222a  Reaf f irm/staf f  Software  Technology  Center 

l.  SS'422A  Define  specific  tasks  to  do  in-house 

a.  SS-121A  Establish  standards  for  software  environments 
a.  SS-23IA  Develop  software  story/lessons  learned 

0.  SS-223A  Establish  software  engineering  program 

p.  SS-223A  Prevent  wholesale  engineer  reclassification 

q.  SS-433C  Provide  staff  for  softwaie  engineer  subprogram 


Import  of  Che  AMC  Sofcvmre  Task  roree 


31 


4.2  IMPLElfXNTATIOM  OEGAMIZATIOI. 


There  is  ao  one  place  la  Che  Army  where  a  sufficient  number  of 
qualified  people  can  be  found  to  Implemenc  Che  recommendac ions  of 
this  study  in  an  integrated  way.  For  that  reason,  a 
mul  t  i-'or  gaol  a  a  c  iona  1  implementation  group  needs  to  be  developed 
which  can  provide  the  focused  and  coordinated  management  which  is 
needed.  An  implementation  group  structured  as  shown  in  Figure 
4.1  is  recommended.  Each  of  the  four  major  ..rork  packages 
discussed  in  Section  III  is  essentially  separable  from  the  others 
and  can  be  managed  by  a  separate  implementation  group.  The  group 
responsible  for  resources  should  be  run  out  of  AMC,  Headquarters. 
The  others  can  be  most  effectively  managed  from  within  AMC's 
subordinate  commands.  Because  of  the  need  to  gain  the  support  of 
Industry  for  many  of  the  efforts,  a  fifth  group  is  suggested  to 
handle  the  interface  with  industry.  Each  group  leader  should  be 
selected  and  identified  by  name  and  the  group  leaders  should  be 
responsible  for  proposing  members  of  their  team.  It  is  important 
that  the  group  members  reflect  a  wide  cross-section  of  the  Army: 
representing  all  appropriate  HACOHs  and  provide  adequate 
functional  diversity.  The  group  leaders  would  be  responsible  for 
detailed  implementation  planning  with  their  group  and  for 
recommending  assignment  of  specific  responsibilities  for  task 
execution.  A  management  team  is  proposad  at  HQ,  AMC  to  provide 
overall  project  management,  identify  resources  required  and 
allocated,  track  accomplishments,  and  keep  all  activities 
coordinated.  A  steering  committee  is  recommended  to  provide 
integration  across  functional  areas  and  an  executive  committee  is 
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proposed  Co  provide  incer^MACOM  oversight.  Although  Che 
compleclon  of  all  che  casks  Identified  la  this  report  vlll  extend 
over  several  years,  IC  Is  recommended  chat  che  Intensive 
management  process  suggested  In  Figure  4.1  have  a  one  year  sunset 
clause.  After  that  time,  Che  Implemencatlon  accomplishments 

should  be  reviewed  by  Che  executive  group.  The  executive  group 

% 

should  decide  whether  to  continue  1 mp leae a ta c 1  on  with  che 
Intensive  management  process  described  herein  or  to  switch  to  che 
normal  management  chain  with  periodic  Jolnt-’MACOM  progress 
reviews.  In  either  case,  che  iaplementaClon  will  require  close 
aanageaeot  atcentlon  and  support  for  an  extended  period  of  time. 


IMPLEMENTATION  APPROACH 


EXECUTIVE  COMMTTTEE 


IMPLEMENTATION  GROUPS 
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APPENDIX  A 


Software  Problem  Taxonomy 


Today  we  tend  to  go  on  for  years,  with  tremendou<t  investments 
to  find  that  the  system,  which  was  not  well  understood  to  start 
with,  does  not  work  as  anticipated.  We  build  systems  like  the 
Wright  brothers  built  airplanes  ~  build  the  whole  thing,  push  it 
off  the  diff,  let  it  crash,  and  start  over  again.” 

R.  M.  Graham 
NATO  Science  Committee 
oonferenoe  on  Software  Engineering 
October7-11,1968 


No  Advocacy  Plan  with  Congress 

La  K  of  awareness  concerning  the  crtticallcy  of  software  is  pervasive  in  the 
Arxv,  and  extends  from  the  lack  of  an  advocacy  plan  with  Congress;  through  the 
„rtlce  jf  Manpower  and  Budget  (0MB),  Office  of  the  Secretary  of  Defense  (OSD), 
ar.j  joinr  levels;  to  the  Program  Executive  Office  (PEO),  and  materiel 
development  organizations.  This  lack  of  awareness  is  clear  regarding  the 
si-pport  for  software  technology  development  advances;  it  is  even  more  clear 
tnat  we  have  failed  to  educate  Congressional,  Department  of  Defense  (DoD), 
0MB,  OSD,  and  Department  of  the  Army  (DA)  leaders  (who  control  funding 
decisions)  on  software  issues  and  to  promote  the  benefits/ returns  of  quality 
software  Investments  to  the  Army. 
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Lack  of  Integration/Consideration  above  Army  Level 

Naivete  on  the  part  of  OSD  is  evident  when  it  appears  as  a  "doer"  rather  than 
as  a  policy  formulator,  resulting  in  poor  coordination  of  critical  service 
software  policies.  As  an  example,  the  Software  Technology  for  Adaptable  and 
Reliable  Systems  (STARS),  although  it  was  well  intentioned,  is  not  tied  to  the 
joint  needs  ^  the  services  or  connected  to  the  problems  of  the  Army.  The 
Joint  Logistics  Commanders  efforts  to  address  software  issues  are  hampered 
because  of  limited  funds  and  personnel  resources  alloted  to  joint  activities. 
Problems  are  perpetuated  by  the  promotion  into  key  positions  of  staff  without 
the  prerequisite  depth  in  technical  software  areas  to  be  effective  in 
improving  the  services'  software  management  capability. 


A-2 
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MCCR  Software  poorly  Understood  outside  of  AMC 

Within  the  Army,,  confusion  exists  regarding  who  has  central  responsibility  for 
software  decisions.  For  example,  the  roles  of  Director  of  Information  for 
Command,  Control,  Communication  and  Computers  (DISC^)  and  the  Office  of  the 
Assistant  Socretary  fnr  Research,  Development,  and  Acquisition  ara  overlapping 
regarding  computer  resources  in  system  acquisitions.  As  a  result,  there  is  n(^ 
body  of  expertise  at  the  Department  level  to  effectively  address  the  policy 
and  funding  issues  of  systems  with  real  time,  embedded  computer  resources. 
General  Officers  of  all  commands  and  Senior  Executive  Service  (SES)  staff 
frequently  assume  their  positions  having  matured  in  a  non-computer-oriented 
world.  Relatively  few  have  subsequently  acquired  the  level  of  computer 
expertise  necessary  to  adequately  identify  problem  areas  In  automated 
programs'  development  or  operational  environments,  or  to  direct  the  most 
effective  solutions. 
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Little  Software  Awareness  at  PEO,  PM,  MSC 

Lictle  software  expertise  exists  at  the  PEO  level.  Thus,  quality  software 
considerations  are  not  engineered  Into  a  system  from  the  concept  and  design 
phases,  nor  are  sufficient  testing  time  and  resources  allowed  In  development 
schedules.  Despite  the  mission  of  the  Life  Cycle  Software  Engineering  Centers 
(LCSECs),  few  PEOs  tap  the  advisory  personnel  and  support  available  to  them 
through  the  LCSECs.  When  the  Centers  are  utilized,  frequently  ^  horizontal 
slice  of  lower  skilled  staff  Is  acquired  rather  than  a  vertical  slice  with  the 
varying  degrees  of  experience  necessary  to  properly  evaluate  and  guide  all 
aspects  of  a  program's  software  decisions.  PEOs  do  not  plan  and  commit 
program  funds  for  this  software  counsel,  nor  do  they  effectively  utilize  the 
Computer  Resources  Working  Group  (CRWG)  or  Computer  Resources  Life  Cycle 
Management  Plan  (CRLCMP)  concepts.  These  mechanisms  exist  to  support  well 
managed  software  acquisition  and  support,  but  their  value  is  unrecognized  or 
they  are  Ignored  as  unessential. 
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Failure  to  get  support  from  PPBES/HW  Colleagues 

Little  understand  lag  of  the  Planning,  Programming,  Budgeting,  and  Execution 
Systems  (PPBES)  process  and  the  need  for  software  vtsiblllty  exists  among 
those  in  the  Army  Material  Command  (AMC)  responsible  for  software  acquisition. 
Likewise,  little  understanding  of  automation  concerns  exists  in  the  Army  among 
those  responsible  for  PPBES  activities.  Without  software  staff  well  versed  in 
bud^it  request  and  review  procedures,  the  needs  of  hardware  invariably 
override  software  funding  reeds.  This  condition  extends  to  spaces  as  well  as 
to  dollars  and  consequently  forces  the  contracting  of  software  work  because 
Army  facilities  are  understaffed  or  underskilled  to  perform  the  work  in-house. 

The  Intent  of  retaining  the  combined  software/systea  expertise  In-house  at  the 
LCSECs  is  thus  frustrated.  We  have  sacrificed  badly  needed  professional  slots 
by  retaining  slots  for  servlco/aiaiatenance-oriented  functions,  which  could 
more  readily  be  contracted  without  ciuslng  stagnation  In  the  growth  of  our 
technical  capability. 


No  Capitalization  of  new  Computer  Engineer  Series 

Alchough  the  Computer  Engineer  job  series  (GS-0854)  has  recently  been  created, 
little  recognition  has  been  given  to  the  fact  that  actually  acquiring  “.hese 
staff  will  be  difficult.  This  is  due  partially  to  the  stringency  of  the 
series'  qualifications  (See  Position  Classification  Standard  for  Computer 
Engineering  Series  GS-854  (TS-83,  January  1988))  and  partially  to  the  lack  of 
a  crossover  program  allowing  current  government  staff  to  acquire  credentials 
necessary  to  transition  to  the  new  series.  Further,  there  does  not  appear  to 
be  career  management  assistance,  either  formally  as  a  personnel  service  or 
informally  using  a  counselor/mentor  approach,  to  guide  personnel  In 
identifying  and  selecting  positions  that  will  foster  their  technical  growth  in 
software  engineering.  Having  no  definitive  career  path  with  recognized, 
required  steps  inhibits  steady  progress  toward  developing  the  Army's  required 
software  engineering  expertise. 
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Best  Students  lost  to  Industry  early  in  College 


yich  lower  entry  level  government  salaries,  the  Army's  ability  to  hire  the 
best  computer  science  graduates  away  from  higher  paying  Industry  opportunities 
is  severely  weakened.  Entry  level  .government  salaries  of  S25,000/yr  put  Army 
recruiters  at  a  great  dlsadvantag  *  competing  with  industrial  offers  of 

$30'40 , OOC/yr .  The  differential  is  clear.  Also,  because  of  their 

concentrated  efforts  tc  attract  college  students  throughout  the  undergraduate 
college  years,  industrial  recruiters  are  far  more  successful  in  signing  up  the 
best  students  wsll  before  graduation.  Conversely,  the  current  Army  co-op 
program  does  not  successfully  cultlvare  students  by  pre-selling  sn  Army 
career,  nor  by  tlelng  the  co-op  program  to  a  geographically  oriented  intern 
recruiting  program.  In  many  Instances,  we  have  failed  to  pmrmanencly  employ 
the  co-ops  we  have  had,  either  because  of  poor  co-op  -  permanent  position 
transition  planning,  or  by  failing  to  create  the  stimulating  technical 

environment  required  to  challenge  new,  eager  graduates,  valuable  staff 

continuity  between  co-op  experience  and  long  term  employees  is  thus  lost. 
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Failure  to  Structure  multi  -  path  Career  Program 

Although  effective  managers  must  have  a  balanced  mix  of  technical  skills  and 
management  experience,  technical  career  growth  is  sacrificed  for  the  more 
attractive  promotional  opportunities  of  the  management  track.  By  limiting  the 
technical  growth  of  our  management  staff,  we  necessarily  deprive  chose  tasked 
with  decision  responsibility  from  obtaining  Che  depth  of  understanding  their 
positions  require  to  make  chose  decisions.  Further,  little  if  any  preparation 
is  provided  to  move  from  the  technical  path  to  management  responsibilities. 
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No  Effective  Technical  Development  Program 

For  chose  elecclag  to  remain  In  che  cechnical  arena,  cralning  courses  do  not 
necessarily  crack  co  a  clear  career  developoenc  scheme.  Disllluslonmenc  also 
frequencly  resulcs  when  scaff  are  noc  uClllzed  In  chelr  expressed  area  of 
Inceresc  (l.e.,  when  engineers  are  noc  used  is  engineers).  Covernmenc 
employmenc  also  offers  less  Incenclves  chan  Induscry  Co  obtain  advanced 
degrees,  an  Imporcanc  recrulclng  advantage  and  career  enhancer  for  computer 
science  graduates.  Considering  Chat  In  these  fast  paced  technology  areas 
computer  science  and  engineering  knowledge  has  a  half-life  of  approximately 
four  years,  continued  educational/  degree  opportunities  arc  high  priority 
Items  for  candidates  weighing  employmenc  options. 
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tsforc  of  eh«  AMC  Software  Teak  forem 


Inadequate  Management  Development  Process 

Management  career  development  is  equally  unstructured.  Opportunities  are  not 
provided  for  managers  to  continue  association  with  the  technologies  of  their 
programs  and  with  the  development  of  management  skills.  These  opportunities 
are  necessary  to  properly  plan,  schedule,  direct,  and  evaluate  their  programs' 
progress.  Only  those  familiar  <<j.th  technology  advances  can  effectively  write 
and  monitor  contracts  so  that  the  best  products  can  be  specified  and  acquired 
for  the  Army.  Effort  must  be  made  to  turn  Army  managers  into  ‘smart  buyers'* 
and  increase  practical  technical  Involvement  to  attract  the  strongest  leaders 
to  Government  service. 
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Talents  and  Education  mis -applied 

The  Issues  surrounding  retention  are  not  unlike  chose  affecting  recruitment. 
They  are,  however,  intensified  because  not  only  does  the  Amy  loose  the  staff, 
it  also  looses  the  benefit  of  the  experience  they  have  acquired  at 
Government/mi lltary  expense.  Engineers  frequently  are  assigned  to  non- 
engineering  work,  and  mid-level  staff  consume  most  of  their  time  responding  to 
bureaucratic  requirements  rather  chan  to  hands-on  technical  assignments. 
Recent  graduates  often  revert  to  industry  to  get  Che  more  challenging 
positions  they  need  to  develop  their  technical  capabilities. 
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Lack  of  Career  Path  for  Military  SW  Experts 

Some  of  the  greatest  drains  are  seen  in  the  military  personnel  area.  Even 
with  strong  credentials  and  performance,  promotional  opportunities  have  been 
sorely  lacking  for  officers  and  enlisted  assigned  to  software-oriented 
billets.  This  pattern  sends  blatant,  negative  messages  and  deters  younger 
officers  who  might  become  valuable  assets  from  moving  into  software  programs. 
Instead,  they  choose  to  leave  the  Army  and  follow  other,  more  career  enhancing 
avenues . 

A  contradiction  is  inherent  in  this  pattern  that  has  not  been  lost  on 
Industry,  even  if  it  is  not  apparent  to  the  Army.  Disillusionment  with 
frustrated  career  progression  makes  mid-level  military  with  a  vital 
combination  of  field  experience  and  academic  or  practical  software  talents 
ripe  for  industry  offers.  With  so  few  "software  smart”  soldiers  In  the  field, 
those  that  do  exist  are  ianediately  Identified  by  industry  as  key  assets  and 
lured  away  by  impressive  salaries  and  advancement  opportunities. 
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Army  Leadership  Illiterate  about  Embedded  SW 

A  consequence  of  Che  mid-level  mlllcary  drain  Is  that  Che  goal  of  developing 
Che  required  body  of  sofcware  knowledge  in  our  senlo.-  Army  leadership  is 
becoming  more  and  more  unaccainable •  We  are  losing  che  young  officers  who 
would  evencually  assume  chose  posicions.  WlchouC  advocaces  ac  che  higher 
policy,  fundtug,  and  prioriclzaclon  levels  of  Army  decision  isakiiig,  aucomaced 
sysceas,  sofcware  cechnology,  and  scaff  developmenc  programs  vlll  continue  co 
suffer  from  naive  decisions  and  funding  deficiencies.  Ocher  services  promote 
sofcware  awareness  In  cheir  senior  ranks  by  having  Central  Officers  presenting 
software  11 tcracy/ Inf ormac ion  programs.  Where  acccmprs  at  laformatlon 
programs  have  been  made  in  cne  Army,  they  have  been  conducted  by  lower  level 
scaff  with  little  or  no  influence  co  affect  constructive  changes.  By 
relegating  such  Important  work  to  lover  levels,  we  perpetuate  a  "software 
second"  mentality  ar.d  delay  effective  action  to  deal  with  software  Issues. 
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Inadequate  Officer  Training  on  Software  Role 

Alchough  multiple  formal  traiaing  courses  are  provided  for  nearly  all  aspects 
of  an  Army  officer's  professional  development,  very  few  opportunities  exist 
for  mission  critical  software  and  computer  resources  training.  Officers  are 
consequently  ill-equipped  to  direct  and  oversee  computer  resources  operations 
in  the  field.  What  training  does  exist  (e.g.,  short  term  assignments  to  the 
LCSECs)  is  generally  limited  to  Junior  level  oficers;  thus,  those  with 
decision  making  responsibility  are  prevented  from  acquiring  sufficient 
knowledge  to  oiake  informed  decisions. 
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Little  Infusion  of  Software  Literacy  for  NCO/ENL 

Little  or  no  advanced  software  technology  infusion  exists  at  the  Non- 
Connnissioned  Officer  (NCO)  and  enlisted  levels  (ENL)  (courses  are  still 
limited  to  COBOL),  yet  these  are  the  people  responsible  to  configure,  operate, 
and  trouble-shoot  complex  automated  systems  in  the  field.  Absence  of  the 
vital  connection  between  the  application  area/weapons  system  knowledge  and 
computer  resources  knowledge  further  prevents  those  trained  in  field 
operations  from  recognizing  and  reporting  software  problems  or  chose  with  only 
Che  software  background  from  recognizing  the  perspective  of  the  soldier  in  the 
field.  Ue  fail  to  recognize  a  great  asset  In  NCO  as  experienced  field 
users,  and  to  assign  them  as  advisors  to  PEOs/PMs  during  Che  development  of 
new  systems.  Yet  chose  few  trained  in  both  arenas  exhibit  the  highest 
comBlcment  to  providing  comprehensive  field  support  while  ensuring  that  the 
software  integrity  remains  intact. 


Import  of  the  ANC  Software  Task  Force 
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Poor  Weapon  System  Knowledge  by  SW  Experts 

In  the  same  way  that  operational  field  officers,  NCO,  and  ENL  are  ill-equipped 
and  trained  to  deal  with  software  issues,  software  developers  frequently  Lack 
the  field  user's  perspective,  understanding,  and  expertise  necessary  to 
analyze  a  new  system's  requirements,  implement  it,  and  thoroughly  test  it  at 
completion.  One  must  either  be  a  good  communicator,  missile  operator,  or 
artillery  controller  to  develop  a  truly  responsive  automated  system,  or  be 
diligent  in  researching  a  given  field  with  the  assistance  of  qualified  domain 
sxpstts.  Current  development  programs  focus  only  on  the  software,  not  on  the 
maturity  of  the  developing  staff's  understanding  of  the  application  domain. 
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General  Lack  of  Software  Ancillary  Skills 

If  training  in  the  developttent  and  operational  concepts  of  automated  systems 
is  lacking,  training  in  such  ancillary  computer  resources  skills  as 
Interoperability,  Quality  Assurance  (QA),  and  Configuration  Hanagement  (CM) 
are  non-existent*  Yet  these  areas,  along  with  knowledge  of  proper 
installation  and  back-up  procedures,  proper  environmental  conditions  and 
preparation  of  systems  for  transport;  and  overall  computer  system  management 
(e.g.,  operating  system  upgrade,  new  software  capability  deliveries,  and 
recovery  from  system  crash)  are  also  crucial  skills  not  being  addressed. 
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Poor  Development  of  Field  Software  Analysts 

Currently  no  program  exists  to  develop  qualified  field  software  analysts. 
E-cause  a  cross-discipline  capability  Incorporating  software  engineering  has 
not  been  realized,  training  for  warrants,  E5s,  and  E6s  with  field  experience 
has  not  been  oriented  to  software  analysis.  A  valuable  link  from  the  user  in 
the  field  to  the  LCSECs  responsible  for  the  computer  systems  support  is  thus 
being  lost.  Field  software  analysts  must  be  experienced  in  many  systems  in 
order  to  be  effsctlve.  While  obtaining  this  broad  range  of  system  knowledge 
is  recognizably  difficult,  we  have  failed  to  use  existing  resources  such  as 
the  LCSECs,  where  systems  with  similar  functionality  are  assigned,  as  a 
training  environment  for  field  analysts. 
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Failure  to  keep  Software  Professionals  Current 

A  lack  of  educaclonal  opportunities  is  a  deficiency  whose  Inpllcations 
affecting  recruitment  and  retention  have  already  been  cited.  The  competency 
level  of  staff  who  ^  remain  in  government  positions  is  also  jeopardized  by 
our  failure  to  keep  software  professionals  current  in  technology  advances. 
While  a  few  full-time  degree  opportunities  as  well  as  part-time  night  programs 
are  available,  the  single  course  approach  (a  good  option  for  subspecialty 
development)  is  underutilized.  This  may  be  because  of  a  lack  of  commitment  to 
educational  funding,  or  perhaps  because  of  a  lack  of  a  mentor  or  guidance 
program  chat  encourages  staff  currently  working  in  automation-  related  fields 
to  acquire  Che  added  skills  to  cross-over  Into  software  engineering. 
Education  is  also  lacking  for  chose  tasked  with  preparing  the  essential 
software  portions  of  RFPs  for  new  procurements,  e.g.,  writing  clear,  concise, 
and  complete  requirements  specifications  or  sclpulating  Che  responsibilities 
and  Interactions  between  prime  and  IV&V  concractors.  UitbouC  proper 
education,  governmenc  and  military  staff  are  also  Ill-prepared  to  critically 
assess  the  quality  of  software  systems  being  delivered  by  concractors;  fonul 
reviews  are  of  little  value  if  the  reviewers  do  not  have  the  require 
technical  foundation  for  evaluating  deliverables  and  services. 
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No  Program  to  Provide  Cross  -  Over  Education 

Because  of  salary  and  technical  considerations  already  cited,  we  cannot 
recruit  enough  software  engineers  directly  out  of  college.  At  the  current 
time,  no  cross-over  program  exists  in  the  Army  to  take  engineers  from  other 
areas  or  former  military  with  valuable  field  experience  and  retrain  them  in 
the  critical  software  engineering  disciplines.  By  doing  without  a  cross-over 
education  program,  we  perpetuate  the  already  critical  lack  of  software 
expertise  in  our  government  staff. 
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Little  Emphesis  on  Software  at  Military  Schools 

An  obvious  deflcleacy  is  that  liccle  or  uo  software  eophasls  Is  present  in  the 
senior  military  schools,  a  failing  that  promulgates  Che  "software  second" 
mentality  and  further  delays  getting  Che  senior  leadership  in  couch  with  the 
criticality  of  software  to  the  services.  Even  at  the  Defense  Systems 
Management  College  (DSMC),  little  education  it  provided  in  the  skills 
necessary  to  direct  an  automated  program.  Inadequately  addressing  the  area  of 
software  management  ignores  an  aspect  of  a  program  with  potentially  the 
greatest  risk  for  preventing  the  timely  cosc-cffecClvc  delivery  and  correct 
field  operation  of  a  complex  weapons  system. 
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No  Distinction  of  Embedded  Software  Peculiarities 

DoD  acquisttioa  policy  pertaining  to  computer  resources  is  based,  in  part,  on 
public  law.  With  the  enactment  of  the  Brooks  Bill  (Public  law  89-306)  in 
October  1965,  the  General  Services  Administration  (GSA)  became  responsible  for 
the  economic  and  efficient  purchase,  lease,  maintenance,  operation,  and 

ft 

utilization  of  automated  data  processing  equipment  by  the  federal  departments 
and  agencies.  The  distinction  was  made  between  general  purpose  business, 
financial  type  applications,  and  the  special  purpose  DoD  weapons  systems 
applications  of  computers.  This  latter  category  of  computer  systems  was 
exempt  from  the  provision  of  the  Brooks  Act.  The  Warner  Nunn  Amendment 
broadened  the  class  of  computer  resources  and  exempted  them  from  the  Brooks 
Bill  and  was  the  genesis  of  the  new  term.  Mission  Critical  Computer  Resources 
(MCCR).  However,  the  distinction  of  MCCR  has  not  been  codified  Into 
regulations,  standards,  and  pamphlets.  This  absence  of  a  systematically 
arranged  and  comprehensively  collected  set  of  procedures  to  provide  a 
distinction  for  embedded  systems  and  their  peculiarities  has  resulted  in  a 
broke  system,  before  it  was  cres'^.-.d,  in  software  acquisition. 
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Confusing,  Overlapping  Areas  of  Responsibility 

While  MCCR  were  developed  and  acquired  under  policies  and  procedures  outlined 
in  DoD  Directives  500C.  1,  5000.2,  and  500.3,  the  Army  directed  the  use  of  Army 
Regulation  (AR)  70*1,  "System  Acquisition  Policy  and  Procedures,"  a  hardware 
only  regulation.  When  C3D  shifted  oversight  of  life  cycle  management  for  MCCR 
by  expanding  the  definition  of  general  purpose  automated  data  processing  to 
include  the  Army  Systems  Acquisition  Review  Council  (ASARC)  and  Joint 
Requirements  .Management  Board  (JRMB)  guidelines  established  In  DoD  Directive 
(DoDD)  5000.1,  the  systems  fell  to  review  by  the  Major  Automated  Information 
Systems  Review  Council  (MAISRC).  There  has  not  been  established  a  focal  point 
for  advocacy,  at  DA  level,  for  mission  critical,  embedded  system  software.  It 
must  be  recognized  chat  mission  critical  systems  are  different  from  Automated 
Data  Processlng/Management  Information  Systems  (ADP/MIS)  and  equal  emphasis 
must  be  provided  for  acquisition  policy,  career  development,  and  budget 
advocacy  for  missiou  critical  software. 


Application  of  AR  70  vs  AR  25  Regulations  Unclear 

The  Army  does  not  have  one  general  policy  defining  an  embedded  tactical 
software  framework.  Numerous  regulations  and  pamphlets  have  been  promulgated 
chat  cover  most  of  the  subsets  of  the  software  life  cycle  process.  However, 
neither  the  PM,  PEO,  nor  the  Army  Acquisition  Executive  (AA£)  can  turn  to  any 
one  policy  document  to  determine  what  constitutes  the  life  cycle  software 
acquisition  process.  For  example,  in  AR  70-1  references  to  hardware  occur 
four  times  more  frequently  than  references  to  software.  There  is  also  no 
mention  of  the  need  to  allow  capitalization  of  software,  that  is,  the  notion 
of  including  in  the  contractor's  assets  his  ability  to  produce  software.  Life 
cycle  acquisition  of  embedded  tactical  software  systems  must  be  done  through 
two  different  policy  channels.  Development  is  done  under  AR  70-1  (with  NO 
supplemental  AMC  regulation). 
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No  Top -down  Plan  to  Address  Software  Policy 

Sofcware  for  embedded  systems  has  never  been  acquired  on  a  life  cycle  basis 
under  one  policy  stream.  The  approach  taken  by  DA  was  to  "force-fit"  software 
into  hardware  regulations  with  no  consideration  for  its  peculiarities.  This 
failure  to  adequately  address  software  in  Army  regulations  and  pamphlets  left 
a  void  that  will  have  a  costly  Impact  for  PDSS  well  Into  the  21st  century. 
There  are  many  regulations  chat  address  (or  do  not  address)  sofcware  In 
various  disciplines;  however,  there  is  little  or  no  consistency  between  these 
regulations  as  Co  how  sofcware  should  be  acquired  and  sustained.  A  major 
problem  created  by  this  Inconsistency  Is  that  there  Is  no  standard  for 
embedded  computer  resources  chat  generate  ever  spiraling  costs. 
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Failure  to  Address  Software  in  Regulations 

Because  AR  70-1  did  not  adequately  address  Che  life  cycle  support  for  emoedded 
software,  AR  70-XX  was  prepared  to  implement  the  DoD  directive.  It  has  been 
in  draft  form  for  several  years  because  of  a  disagreement  between  Headquarters 
and  DA  activities  over  the  proponency  for  embedded  systems.  This  lack  of  Army 
policies  and  procedures  for  embe'^ded  systems  has  negatively  affected  the 
development  and  support  of  software  over  Che  past  12  years.  During  this  time, 
tactical  software  programming  languages  proliferated  and  software 
supporcability  was  not  built  into  many  systems.  Consequently,  the  Army  does 
not  have  the  means  to  effectively  and  economically  support  much  of  its 
tactical  software. 


Lack  of  Consistency  between  Regulations 

A  lack  of  coasistency  becween  regulations  and  standards  generated  ingrained 
developmental  problems  that  will  cause  a  continued  spiraling  effect  tn  support 
cost  for  anotner  15  years.  This  lack  of  consistency  failed  to  provide  the 
means  to  adequately  build  software  supportabillty  into  most  embedded  systems 
because  the  Army  did  not  have  sufficient  oversight  for  supportabillty.  The 
root  cause  of  inadequate  supportabillty  was  that  planning  (lack  of  standards 
promulgated  by  regulations)  for  software  support  either  was  not  accomplished 
or  was  not  adequate.  As  byproducts  of  poor  software  plaanlng,  adequate 
software  documentation  and  software  support  environments  were  not  acquired. 
The  recent  emergence  of  OoO  Standard  2167a,  '’Defense  System  Software 
Development,"  and  DoD  U67  (AR),  “Military  Standard  Software  Support 
Environment."  will  eventually  combat  these  problems.  However,  neither  AE  70-1 
or  AR  25-1  recognizes  these  critically  needed  standards  for  directing  the 
effective  and  economical  support  for  embedded  software.  Without  adequate 
software  documentation  and  support  environments,  the  Army  does  not  possess  the 
means  to  change  tactical  software  to  keep  pace  with  new  doctrines  for  threats, 
to  enhance  system  effectiveness,  or  to  correct  system  deficiencies. 
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No  Process  to  Force  Regulatory  Compliartce 

The  Army  has  noc  Issued  regulatory  guidance  to  implement  DoDD  5000.29  for  the 
management  and  control  of  embedded  tactical  systems.  Lack  of  Army  policies 
and  procedures  has  created  a  void  for  the  implementation  of  a  process  to 
enforce  and/or  review  regulatory  compliance.  Without  a  review  process, 
proliferation  of  tactical  software  has  been  unchecked,  and  software 
supportability  has  not  been  built  into  embedded  tactical  systems.  Had  the 
Army  implemented  DoDD  300G.29  and  its  policies,  there  would  have  been  a 
framework  to  create  organizational  structure  and  systematize  procedure  and 
review  compliance.  Unfortunately,  this  organization  has  never  been  created 
because  of  conflicting  regulations  and  Che  basic  lack  of  embedded  software 
advocacy  at  the  DA  level  with  the  requisite  authority.  As  a  result,  no 
oversight  system  has  been  established  at  the  Major  Command  (MACOH)  level  for 
computer  resources  planning,  software  language  standardization,  configuration 
management,  and  software  supportability. 
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Failure  to  Identify  Systemic  Problems 

Failure  to  identify  systemic  problems  was  a  negative  fallout  from  the  lack,  of 
the  aforementioned  process.  Computer  Resources  Management  Plans  (CR.MP)  were 
not  prepared  for  many  embedded  systems,  which  usually  resulted  in  the  after 
the  fact  efforts  to  create  the  essential  software  support  environments  before 
a  new  embedded  system  was  fielded.  CRWCs  were  also  not  established  for  most 
embedded  systems  resulting  in  no  effective  monitoring  of  the  systems'  software 
development.  Many  of  the  quality  factors  critical  to  maintenance  were  not 
built  into  the  software  system;  therefore,  the  correction  of  refinements  and 
flexibility  of  enhancement  were  costly  or  Impossible  without  total 
redevelopment.  Inadequate  software  documentation  was  also  a  situation  in  the 
majority  of  many  embedded  systems.  As  a  consequence,  clear  details  about  the 
instructions  and  definitions  that  make  up  computer  programs  and  thorough 
information  on  computer  program  functions,  capabilities,  and  operations  were 
not  available  for  software  support.  These  systemic  problems  irere  never 
identified  until  the  later  1980s  when  system  software  maintenance  costs  became 
so  high  that  the  programming  and  budgeting  processes  received  substantial 
dollar  cuts  because  there  was  no  reasonable  Justification  for  the  high  costs. 
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Lessons  Learned  not  Passed  On 

Because  there  had  been  no  means  of  identifying  systemic  problems,  any  lessons 
learned  on  how  to  affect  viable  software  policy  generally  remained  at  the 
lowest  acquisition  or  support  level.  When  a  PM  learned  that  a  CRWG  could 
generate  a  functional  CRMP  chat  resulted  in  positive  support  for  an  embedded 
system,  it  remained  locked  within  the  closed  loop  of  the  PM  or  software 
support  center.  There  were  no  lessons  learned  for  feedback  to  othar  PMs  that 
were  not  performing  adequate  development  of  computer  resources;  therefore,  no 
realistic  audit  trail  as  to  Che  insight  of  software  development  was 
established. 
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Policy  not  Current  with  Latest  Technology 

Progress  to  meet  sophisticated  software  technology  thrusts  through  viable  Army 
policy  is  essentially  non-existent.  Currency  of  policy  or  the  lack  thereof 
has  been  the  most  prominent  reason  for  uncontrolled  computer  language  and 
microprocessor  proliferation.  One  example  of  no  existing  policy  for  emerging 
technology  is  the  total  lack  of  Programmable  ftead-On^  Memory  (PROM)  and 
Erasable  Programmable  Read-  Only  Memory  (EPROM)  technology  Insertion  into 
development  of  new  embedded  systems.  Another  it  the  lack  of  reuse  of  software 
components  among  concurrent  developments.  An  evaluation  of  the  Advanced  Field 
Artillery  Tactical  Data  System  (AFATDS)  and  Maneuver  Control  System  (MCS)  Ada 
software  developments  revealed  that  reuse  of  components  bmtween  the  two 
similar  (command  and  control)  systems  was  noneslstanc.  Policlaa  arm  not 
current  to  direct  this  type  of  technology  insert  ion/ Innovation  into  the 
contracting  and  prcposal  evaluation  process. 
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Regulations  Hamper  Technological  Innovation 

On  Che 'whole  nose  regulations  pertaining  to  computer  hardware  and  software 
acquisition  tend  to  prohibit  or  omit  the  encouragement  of  technical 
innovation.  The  need  for  a  generic  software  program  points  out  this 
regulation  void.  Generic  software  from  one  view  point  might  create  both  a 
technical  base  that  addresses  technology  for  tomorrow  and  an  engineA’ing  base 
that  supports  today's  problems.  This  concept  is  certainly  not  a  rote 
application  of  technology  but  an  initiative  that  would  span  many  systems;  thus 
providing  for  a  reduction  in  developmental  and  sustainment  costs.  An  apparent 
problem  that  exists  is  the  embedding  of  technology  in  policy.  One  such 
example  of  this  is  DoO*-STD-2167a,  which  places  the  traditional  waterfall 
approach  to  software  development  as  an  obstacle  to  innovation  in  a 
technological  sense. 
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Rote  Application  of  Policy  Hampers  Initiative 

An  embedded  system  should  be  predicated  on  the  state-of-the-art  technology 
only  when  Che  benefits  of  the  new  technology  offset  the  accompanying  risks. 
This  principle  is  easy  to  state,  but  it  is  hard  to  apply  because  of  the 
difficulty  in  getting  reliable  information  with  which  to  assess  the  trade-off 
of  risks  and  benefits.  The  only  consistently  reliable  means  of  getting  such 
information  is  by  building  prototypes  that  embody  Che  new  technology. 
Prototyping,  either  at  the  system  or  critical  subsystem  level,  should  be  done 
for  all  new  system  starts.  Operational  tests  should  bm  combined  with 
developmental  tests  of  the  prototype  to  uncover  operational  and  technical 
deficiencies  before  a  decision  is  made  to  proceed  with  development.  At 
present  there  is  no  policy  or  regulation  that  addresses  prototyping  and 
testing  in  the  early  stages  of  development,  but  does  not  present  obstacles 
that  prohibit  tech.ncloglcal  innovation. 
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Requirements  Cannot  be  Fully  Defined  Early 

As  stated  by  the  1983  Army  Science  Board  Study  on  Acquiring  Army  Software, 
"the  most  significant  cost  and  schedule  growth  drivers  for  software  are 
requirements  and  specifications  changes."  Changes  are  inevitable  and  the  rate 
of  change  will  increase  based  on  the  enemy's  technology  explosion  and  the 
stability  of  the  fiscal  program  for  a  system  based  on  its  perceived,  not 
actual,  DA  priority.  Rapid  prototyping,  for  all  its  hype,  is  rarely  a  reality 
that  can  effectively  validate  functional  requirements.  "A"  ■  and  "B” 
specifications  usually  become  Che  casualty  of  a  program  cut,  which  leads  to 
inaccurate  design,  testability,  and  last,  but  most  costly,  supporcabillcy. 
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Schedule  Driven  Software  Development  Process 

Poor  initial  software  requirements  definition  and  subsequent  requirements 
changes  usually  result  in  cost  escalations  and  schedule  delays*  The 
enforcement  of  disciplined  software  requirements,  change  control,  and 
configuration  management  after  requirements  definition  rarely  rerults  in  a 
stable  functional  software  baseline.  When  a  development  falls  behind 
schedi’l*!,  all  management  focus  is  placed  on  code  generation.  Usually  the 
first  software  product  to  be  cut  is  documentation  relating  to  design,  code, 
and  Integration.  Testing  suddenly  is  only  viewed  at  the  system  level,  with  no 
test  or  integration  of  modules  or  packages.  Without  quality  of  design, 
realistic  test  plans  cannot  be  generated,  and  a  system  may  be  fielded  that 
does  not  meet  operational  requirements.  This  Chen  drives  the  requirements  for 
Ocher  Procurements  Army  (OPA)  and  Operations  and  Meinteneece,  Army  (OKA) 
dollars  well  above  the  programmed  level  for  planned  suscaiomenc. 
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Need  for  SupportabiSity  Rarely  Considered 

Once  the  software  development  process  becomes  schedule  driven,  chances  become 
low  with  regard  to  retaining  the  necessary  programmed  dollars  for  adequate 
software  documentation  and  software  support  environments.  This  in  turn 
consumes  a  disproportionate  percentage  of  resources,  thereby  preventing 
allocation  of  sufficient  resources  to  new  systems  to  ensure  that  they  will  be 
supportable  when  fielded.  This  domino  effect  then  increases  the  cost  of 
refinements  and  enhancements  since  much  of  the  software  has  to  be  reverse 
engineered . 
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Enhancement/Modification  Process  Uncontrolled 

With  no  requirements  stabilization,  system  design  usually  fails  co  anticipate 
need  for  growth.  Another  result  of  uncontrolled  modifications  is  the  lack  of 
interoperability.  This  has  had  a  drastic  effect  on  the  electronic  ability  to 
command  and  control  the  battlefield.  Few  systems  have  the  ability  to 
intraoperate  within  their  functional  node,  and  certainly  only  a  limited 
capability  exists  to  interoperate  between  functional  nodes.  All  of  these 
issues  relate  to  the  policy  problems;  they  are  a  fault  of  NO  acquisition 
methodology  within  the  Army. 
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CRMP  Ineffective  for  Program  Management 

Planning  for  the  software  support  of  automated  tactical  systems  Is  not 
adequate.  CRMPs  (plans  for  the  life-cycle  support  of  automated  tactical 
systems  and  related  software)  often  are  not  prepared.  Computer  plans  that 
were  prepared  generally  lacked  sufficient  details  and  In  many  Instances  were 
simply  boilerplate  In  nature.  CRMP  have  not  been  prepared  In  a  timely  manner; 
thus  uncoupling  the  plan  from  the  PM's  acquisition  strategy.  The  prescribed 
format  and  content  for  CRMPs  encourages  them  to  be  composed  of  boilerplat's  in 
a  voluminous  manner  and  contain  little  strategy  with  superfluous  and 
irrelevant  material.  The  CRMPs  are  essentially  stand  alone  documents  not  tied 
to  acquisition  strategy  planning.  They  do  not  consider  the  incorporation  of 
various  matrix  functions  such  as  quality  aasurance,  configuration  management, 
or  RAM.  They  are  also  not  suitable  as  a  management  tool  because  they  omit 
critical  strategic  conside rations  such  as  data  rights,  contractor  vs.  in-house 
support,  and  funding  and  manpower  requirements.  All  of  this  produces  an  air 
of  "what  good  are  CRMP",  which  results  in  no  impact  toward  a  successful 
development  or  sustainment. 
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No  Macro  Level  Capability  for  Resource  Planning 

The  prime  essenca  of  the  CRMP  Is  to  serve  as  a  planning  document  for  computer 
resource  acquisition  and  sustainment.  There  Is  no  funding  mechanism  for  top- 
down  or  bottom-up  program  requirements  that  support  the  CRMP.  Funding  data  is 
rarely  visible  within  the  appropriation  line  for  system  software.  Funding 
data  to  provide  requisite  fiscal  visibility  at  the  DA  level  Is  possible  If 
adequate  hardware  and  software  data  were  spelled  out  in  the  CRMP.  To  become  a 
dynamic  document  it  must  Incorpate  not  only  a  currency  In  technology  and 
timing  with  system  development,  but  also  a  total  coverage  of  all  the  facets 
necessary  to  make  It  a  viable  document. 
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CRMP  Process  Totally  Out  -  of  -  confrol 

CRWGs  (groups  that  meet  to  ensure  that  the  policies,  procedures,  plans,  anu 
standards  established  for  automated  tactical  systems  and  related  software  were 
followed)  generally  have  not  been  established  or  established  when  required. 
Policy  on  software  support  planning  at  the  DA  level  is  vague;  Army  regulations 
mention  computer  plans  and  working  groups  but  contain  few  details  on  their 
nature  and  use.  Controls  at  the  AMC  have  not  been  effective  in  getting 
materiel  developers  to  prepare  detailed  and  prompt  computer  plans  and  to 
establish  working  groups.  This  has  resulted  in  inadequate  software  support 
environments  among  automated  tactical  systems.  Thus,  software  supporcablllty 
is  not  built  into  many  systems,  and  the  Army  cannot  cost-effectively  support 
tactical  software  or  readily  change  it  during  a  conflict.  One  prime  example 
of  the  control  problem  has  been  Ada  waivers.  Many  systems  went  into  full 
scale  developmcit  without  Ada  well  after  the  prescribed  dace  for 
standardization  of  the  language.  When  CRMPs  are  prepared,  many  times  they 
have  been  done  after  development  is  well  underway  and  after  most  critical 
software  decisions  have  been  made  by  default.  This  ex  post  facto  situation 
resulted  in  greater  proliferation  of  computer  resources,  which  drove*  costs 
even  higher. 
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Inconsistent  Funding  Policy 

Fur.ding  for  life  cycle  software  support  has  also  developed  into  an  inexacting 
science.  Although  there  is  a  well  defined  way  as  to  hew  software  is 
developed,  the  challenge  lays  in  what  the  level  of  funds  must  be  in  a  given 
phise  of  tne  life  cycle.  The  level  of  funding  in  each  phase  of  the  life  cycle 
for  an  embedded  system  may  well  affect  the  quality  of  the  software.  if 
do' '..its  are  not  sufficient  during  the  development  phase,  resultaac  software  be 
low  in  quality,  thus  impacting  its  reliability.  Ail  of  the  uncertainty 
surrounding  software  production,  it's  value,  and  how  many  resources  are 
needed  to  develop  and  sustain  Ic  has  resulted  in  a  highly  unstable  fiscal 
prograa.  In  the  last  eight  years  funding  policy  has  changed  five  tiaes  at  the 
DA  level  with  different  interpr itationa  at  the  MACOM/Materlal  Systaa  Coaputer 
(HSC)  levels.  The  Prograa  Objec.lve  Mcaorandua  (POHM)  for  Life  Cycle  Software 
Support  (LCSS)  has  never  been  adequately  justified  sC  Che  DA  level,  and 
therefore  has  continued  to  be  underfunded  and  cut  sonually.  This  situation 
has  developed  to  the  extent  that  there  are  insufficient  funds  co  support  the 
software  In  aany  tactical  sysecas. 
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Little  Basis  for  Software  Cost  Estimates 

The  intrinsic  nature  of  software  and  the  labor  cost  necessary  to  produce 
quality  software  place  software  in  its  own  category.  Software  is  totally 
different  than  hardware.  It  is  difficult  to  show  an  analogy  for  the 
production  of  software.  There  is  no  quantifiable  end  product  chat  can  be  seen 
or  felt.  The  mere  fact  chat  software  is  an  inexact  science,  compared  to  the 
exacting,  disciplined  hardware  engineering  world,  also  Increases  software  cost 
and  makes  it  difficult  to  define  its  worth  or  value.  This  is  what  an  engineer 
is  faced  with  when  trying  to  estimate  Che  cost  of  a  software  development. 
Rarely  are  cost  estimate  properly  conducted  by  the  Army,  and  when  they  are 
accuracy  is  generally  less  chan  50Z.  This  leads  to  the  perception  that  it  is 
not  possible  to  conduct  an  accurate  cost  estimate. 
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Inability  to  Show  Impact  of  Underfunding 

Tnere  are  numerous  models  that  aid  in  prediccing  the  costs  associated  with  the 
LCSECS,  but  the  knowledge  base  to  define  the  requirements  data  Is  also  an 
inexacting  science.  Definition  of  requirements  continually  fails  to 
adeq'<atoly  establish  a  recognized  process  with  a  stable  foundation.  The  "how 
to"  for  defining  requirements  always  reverts  to  the  "from  what",  and  it  is  the 
"from  what"  that  is  usually  nonexistent.  From  this  very  shaky  means,  the 
requirements  for  dollars  are  built  into  a  program  for  each  system. 
Invariably,  the  total  cost  of  the  entire  program  exceeds  Che  "expected  cost", 
and  underfunding  results.  When  this  happens  there  is  panic  because  there  Is 
no  realistic  means  to  show  Impact  based  on  the  original  ill'defined 
requirements. 
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Lost  Software  Engineering  Opportunities 

What  is  the  impact  of  reduced  funding  or  poor  fiscal  directives?  LCSECs  are 
consistently  underfunded  in  both  core  and  system  specific  dollars,  and  the 
result  is  lost  software  engineering  opportunities.  When  critical  software 
refinements  and  enhan(.ements  are  not  accomplished  for  fielded  systems,  combat 
effectiveness  dimlni.shes.  Technical  expertise  Is  lost  through  Che  turnover  of 
experienced  people.  A  ^aore  insidious  effect  Is  the  diversion  of  funds  which 
were  intended  to  support  research  and  development  activities  In  order  to  meet 
basic  maintenance  or  sustainment  requirements.  Without  the  Investment  to 
improve  the  process  and  to  ensure  that  new  systems  are  better  engineered  than 
existing  systems,  Che  Army  is  Just  building  up  larger  unfunded  liabilities. 
The  opportunity  to  reduce  the  support  cost  of  future  systems  is  lost. 
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Failure  to  Execute  Realistic  Software  Planning 

Funding  policy  for  LCSECs  is  so  complex  that  the  difficulty  io  developing  a 
yearly  fiscal  program  has  created  an  undefinable,  nonquantifiable  monster  chat 
generally  is  interpreted  differently  at  each  successively  higher  level.  The 
LCSEC  has  a  hard  time  supporting  the  funding  requirements,  and  each  successive 
level  understands  Che  requirements  less  (or  not  all),  until  they  reach  DA,  * 
which  has  only  a  “two  liner**  to  justify  an  exorbitant  funding  level.  As  a 
result,  Che  amount  funded  has  been  less  than  half  of  Che  stated  requirement. 

If  there  were  a  proponent  at  each  level  that  could  articulate  the  LCSS  story, 
Che  program  would  probably  survive;  however,  this  is  not  the  caam.  This  is 
further  confused  by  chose  chat  dittate  funding  policy,  without  having  the 
experience  or  understanding  of  the  total  LCSS  process. 
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Need  Better  Handoff  Between  AMC  and  TRAOOC 

Relationships  and  responsibilities  between  the  AMC  LCSECs  and  the  TRADOC, 
Tactical  Software  Division  (TSD)  in  five  of  the  six  major  battlefield 
functional  areas  create  a  well  defined  and  highly  cooperative  environment. 
However,  the  remaining  functional  area,  communications,  is  a  loosely  coupled 
relationship.  Factors  that  contribute  to  this  less  than  satisfactory 
situation  are  no  collocation  and  a  combat  developer  with  insufficient 
experienced  personnel  to  adequately  perform  their  mission.  Communications 
between  the  PM  and  TSSM  in  many  systems  are  also  lacking.  This  has  resulted 
in  software  modifications  being  made  to  a  system  by  the  PM  without  a  valid 
requirement  from  the  TSD.  In  the  area  of  duplication  of  effort  between  the 
LCSECs  and  TSDs  there  is  essentially  none,  they  each  support  different  aspects 
of  the  development  and  sustainment  process. 


Support  for  Training  Devices  has  been  Fumbled 

There  Is  no  policy  concerning  LCSS  for  training  devices.  When  the  PDSS 
laplementatlon  Plan  was  revised  to  become  the  Life  Cycle  Software  Engineering 
(LCSE)  Plan,  training  devices  were  omitted.  Funding  policy  for  training 
devices  concerning  LCSS  is  also  nonexistent.  This  has  resulted  In 
nonavailability  of  dollars  that  has  been  the  underlying  reason  for  AMC  LCSECs 
not  accepting  training  devices  that  fall  within  their  functional  area.  The 
complixlcy  and  uniqueness  of  training  device  software  has  bean  a  deterrent 
with  LCSECs  wanting  to  accept  something  that  would  require  concentrated 
training  to  provide  the  requisite  technical  support.  Another  underlying  cause 
is  that  the  lack  of  policy  has  nt  required  the  LCSECs  to  become  involved 
early  in  each  program  Initiation. 


Functional  Duplication  Still  Prevalent 

There  has  been  great  concern  over  functional  duplication  between  LCSECs  and 
support  activities  such  as  Product  Assurance  and  Test  (PA&T)  Directorates  at 
each  MSC.  The  only  factual  documented  duplication  of  effort  that  exists  is 
between  the  LCSEC  and  PAiT.  PA&T  has  the  charter  to  sign  (verify)  for  the  MSC 
Commander  on  all  material  releases.  In  order  to  perform  this  task  some  MSCs 
have  required  PA4T  to  conduct  IViV  on  each  new  software  version  prior  to  its 
release  and  distribution  to  the  field.  The  LCSEC,  however,  is  charged  with 
ensuring  software  quality  for  all  software  products.  It  also  must  certify 
that  every  software  release  Is  supportable  by  signing  a  statement  of 
supportablllty.  Most  Importantly,  the  LCSEC  must  be  able  to  support  the 
software  once  It  Is  fielded.  For  the  LCSEC  to  certify  supportablllty  and  then 
actually  perform  modifications  to  software  once  It  Is  fielded  requires 
constant  training  and  famlllarlsatloa  with  the  development.  This  Is 
accomplished  through  review  of  all  software  deliverables,  design  and  code  walk 
throughs  (awdlts),  verlf Icatlon/valldatlon  of  module  and  Integration,  and 
complete  acceptance  testing.  The  PAAT,  In  the  conduct  of  Its  IV4V  activities, 
must  maintain  competence  In  the  same  areas  and  duplicate  many  of  the  same 
activities. 
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Lack  of  LCSEC  Accountability 

There  is  an  Army  implemencacion  plan  for  the  establishaeac  of  pose  deploymenc 
software  support  centers-  This  plan  was  later  revised  to  Incorporate  the 
software  life  cycle  concept,  and  an  LCSS  implementatioa  plan  was  established. 
These  plans  detail  what  the  mission  and  functions  ot  a  center  are  and  define 
the  functional  areas  for  each  center's  system  support.  Absent  from  the  plan 
is  the  requirement  for  each  center  to  establish  Internal  controls  with  a 
mechanism  of  accountability  to  AMC.  When  the  LCSS  plan  was  established, 
systems  were  defined  by  functional  areas.  The  plan  has  not  been  updated  since 
1983;  therefore,  a  current  database  of  systems  and  computer  resources  is  not 
maintained  at  each  center. 


Import  of  tho  AMC  toftvoro  Took  force 


4-4f 


AMC  not  Effective  Player  in  Software  Management 

The  Army  reorganlzacion  under  che  Packard  Recommendations  established  an  Army 
Acquisition  Executive  (AA£).  This  reorganization  eliminated  the  Deputy  Chief 
of  Staff  for  Research,  Developments  and  Acquisition,  and  established  the 
.Assistant  Secretary  of  the  Army  for  Research,  Development  and  Acquisition 
(ASARDA).  At  the  same  time  it  redesignated  the  Assistant  Chief  of  Staff  for 
Information  Management  to  be  the  OISC^.  Responsibility  for  weapon  systems 
(software)  was  transferred  from  ASARDA  to  DISC^.  DISC^  is  now  taking  the 
philosophy  that  embedded  software  is  no  different  than  MIS  software  and 
therefore  is  applicable  to  one  Army  Regulation,  specifically  AR-*2S-scries> 

The  reorganization  also  established  che  Program  Executive  Office  (PEO)  Concept 
for  management  of  system  acquisition.  The  PEO  concept  removed  PMs  from  under 
Che  technical/ fiscal  control  of  AMC  end  "stove  piped”  them  directly  to  DA  (AAE 
or  DISC^}.  These  cwo  actions  have  essentially  defused  AMC's  ability  to  menage 
software  development,  but  they  leave  AMC  with  the  responsibility  to  maintain 
software.  While  there  was  a  direct  cr  rdlnation  link  between  DCSRDA  and  AMC, 
it  is  not  true  for  DISC4  and  che  AMC  weapons  systems  staff.  Additionally,  the 
A.MC  weapon  system  staff  was  reduced  to  a  level  of  ineffectiveness  concurrently 
with  che  DA  reorganlzacion.  The  reorganlzacion  has  also  failed  to  establish  a 
strong  proponent  (advocate)  for  software  or  a  champion  in  fiscal  policy  and 
budget  in  LCSE  matters. 
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Inadequate  Internal  Controls 

Inceraal  concrols  for  sofcware  management  are  not  adequate.  The  lack  or 
effectiveness  of  these  results  in  poor  planning  for  embedded  systems  by 
insufficient  sofcware  supportability ,  inadequate  sofcware  documentation  and 
sofcware  support  environments,  and  nonstandard  programning  languages. 
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PEOs  Appear  independent  of  AMC  Control 

The  PEO/PM  process  appears  to  be  operating  independently  independently  of  AMC 
management;  therefore,  AMC  regulations  such  as  70-16,  "Computer  Resources 
Management,”  have  been  considered  inapplicable  by  the  PEOs/PMs.  Another 
negative  aspect  is  that  PMs  now  have  the  latitude  to  look  upon  an  LCSEC's 
recommendations  on  software  development  and  support  as  advisory.  The  PM  may 
or  may  not  chose  to  follow  the  LCSEC's  recommendations.  Many  times  sound 
technical  and  programatic  recommendations  are  ignored  in  an  attempt  to  save 
time  or  money  in  the  development  process. 
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No  Army  Software  Technology  Proponent 

Technology  proponency  has  been  a  void  at  che  DA  and  MACOM  levels.  This  lack 
of  technical  direction  is  probably  the  most  serious  factor  tr.at  onderatnes 
the  future  of  the  embedded  tactical  systems  program.  Wh.le  some  arteipts  nave 
been  made  to  institute  technical  advocacy,  they  have  beer,  feeoie  at  best.  One 


such  attempt  was  the  estnbl Ishment  of  a  Software  Technology  Center  to  support 
all  AMC  .Mission  Critical  Computer  Systems.  Lacking  the  technology  proponent 
to  provide  necessary  guidance  and  resources,  the  Center  has  been  underfunded 
and  inadequately  staffed.  This  has  resulted  in  a  limited  number  of  technology 
initiatives  and  has  limited  the  scope  of  those  efforts  which  were  started. 
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Poor  Overall  Management  and  Control  of  Software 

Overall  qaanagement  and  concrol  of  software  engineering  practices  have  been 
neither  acknowledged  nor  applied  sufficiently  at  LCSECs.  This  is  the  result 
of  the  splintering  of  hardware  and  software  life  cycle  activities  without 
providing  adequate  authority  and  coomunicatlon  to  integrate  a  systeas  approach 
into  software  development.  The  past  relationship  of  the  PMs  with  software  and 
hardware  support  centers  has  been  based  on  sys tea-specific  agreements  instead 
of  sound  software  aanageaent  and  control  practices.  Failure  to  standardize 
methods  in  software  development  inevitably  lead  to  advers's  impacts  on 
performance,  cost,  schedule,  and  supportablllty. 
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Little  Management  of  Development  and  Methodology 

Tae  Aray  has  never  inscicutea  a  comprehensi vs  process  for  managing  che 
development  of  software  tor  MCCR.  This  void  coupled  with  tne  lack  of  a 
defined  methodology  nas  been  a  key  factor  in  tar  spiraling  of  development 
costs  combined  with  poor  quality  application  software* 

The  simple  fact  chat  software  or  computer  programming  is  an  incxacing  science 
begs  for  discipline.  This  has  introduced  che  technology  of  software 
engineering  as  che  requisite  science  for  instilling  che  needed  discipline; 
however,  this  has  not  been  an  easy  process.  A.MC  and  TRAOOC  have  a  set  policy 
(means)  for  developing  any  new  tactical  system.  This  policy  has  not  Included 
che  significance  of  software  In  cost  and  at  a  daflna^'le  process.  Combload 
with  this  process  has  also  been  che  lack  of  managemanc  directives  chat  could 
be  translated  Into  standards  to  establish  cha  productivity  and  quality 
measures  necessary  for  good  sofcwara. 
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Configuration  Control  not  Enforced 

Software  Configuration  Control  practices  throughout  AMC  are  uncoordinated  and 
poorly  defined.  Issues  of  concern  include; 

(1)  Timely  availability  of  software  changes 

(2)  Adherence  to  the  baseline 

(3)  Adequate  auditing  procedures 

(4)  Compatibility  of  standards  and  documentation. 

System  configuration  control  should  ensure  that  integrated  procedures  address 
the  total  system  requirements,  including  such  items  as  hardware,  related 
CSCIs,  support  and  training  elements  and  facilities,  and  Government  furnished 
hardware  or  software,  as  applicable.  CM  should  also  be  performed  on  all  non- 
deliverable  software  used  in  the  development  and  on  revisions  to  commercially 
available  computer  resources,  as  described  in  either  the  SCMP,  SDP,  or  system 
CM  plan. 
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Transition  to  the  Use  of  Ada  Unplanned 

The  latest  Army  Ada  Introduction  Plan  Is  over  five  years  old.  In  a?'ftlon,  it 
has  only  been  recently  that  any  Army  policy  on  the  use  of  Ada  was  forthcoming. 
A.MC  policy  has  specifically  established  Ada  as  the  POL  and  implementation 
language  for  major  modifications  to  MCDS  software  and  all  new  software 
developments.  It  should  be  noted,  however,  that  there  is  a  lack  of  a  formal 
.4rmy  Regulation  (AR  70‘XX)  to  state  that  Ada  is  the  required  POL.  PMs  have 
not  been  indoctrinated  with  the  benefits  of  utilizing  Ada  and  Its  programming 
support  environment  to  the  degree  that  they  would  make  a  vllllng  commitment. 
PMs  do  not  fully  realize  the  necessity  to  Implement  Ada  In  current  system 
acquisitions.  The  LCSS  Implementation  Plan  has  not  been  updated  since  1983 
and  therefore  does  not  not  reflect  the  current  situation  with  respect  to  Ada 
methodologies,  tools,  or  training.  New  systems  that  have  started  with  Ada  and 
systems  that  have  been  redeveloped  (converted)  to  Ada  have  experienced 
painful,  costly  problems.  This  can  be  traced  to  the  lack  of  a  plan  for 
standard  Ada  tools  and  training  of  software  engineers  and  program/ project 
personnel. 


No  Strategy  for  Software  Environment  Selection 

For  most  systems,  there  have  been  no  controls  placed  upon  the  software 
development  environment.  aMC  started  developing  a  standard  Ada  based  software 
environment  in  1982.  This  process  can  be  portrayed  as  a  coat  of  many  colors: 
Each  passing  year  has  taken  on  a  new  shade  to  comply  with  the  current 
thoughts,  with  no  detailed  planning.  This  evolution  ended  when  the  Ada 
environment  effort  was  cancelled  in  1986  with  the  intent  to  define  commercial 
tools  that  would  serve  as  the  foundation  for  the  first  standard  environment. 

As  of  1989  this  effort  has  never  been  initiated  or  funded. 
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Software  tools  not  Integrated;  lack  solid  Foundation 

While  the  selection  ana  engineering  of  computer  hardware  for  a  software 
support  environment  has  been  relatively  uncomplicated,  the  emergence  of 
software  development  and  support  tools  continues  to  pose  difficult  technical 

challenges.  The  absence  of  any  effective  standard  languages,  host  computers, 

% 

and  target  processors  has  compounded  the  problem  because  the  embedded  support 
environments  are  target/ language  specific.  Even  discounting  these  factors, 
however,  the  Army  face-  a  significant  problem  because  the  tools  which  have 
been  used  to  build  our  systems  have  no  foundation  in  any  sound  methologlcal 
basis  nor  are  they  Integrated  in  any  meaningful  way.  The  need  for  the 
definition  of  a  technologically  sound,  complete  integrated  complement  of  tools 
must  be  the  basis  for  technological  productivity  cf  software  development. 


Army  still  must  cope  with  Numerous  Languages 

The  Army  still  must  cope  with  numerous  languages.  This  has  occurred  through 
the  lack  of  standardization  in  computer  processors  and  languages.  With  a 
proliferation  of  target  microprocessors  there  has  been  a  high  requiremert  for 
support  environments  to  host  the  uncommon  targets.  This  also  is  true  with  the 
proliferation  of  computer  languages.  The  requisite  tool  sec  for  a  support 
environment  tha'  hosts  three  different  languages,  as  compared  to  one,  is  far 
greater.  MCCR  presently  total  143  languages  and  92  microprocessors  that  are 
all  different  through  customized  chips  and  progranmlng  languages.  What  does 
this  mean  in  terms  of  resources  to  support?  Cost  is  skewed  toward  training 
software  engineers  to  comprehend  more  chan  one  language  and  hardware  system, 
iu  addition  CO  Che  need  to  use  very  costly  environments  of  host/ target 
computers  for  each  unique  language  and  associated  processor.  There  must  then 
be  a  maintenance  f^upport  environment  to  support  such  uniqueness  %rlth  Che 
requisite  strategy  to  upgrade  each  system  during  its  lifecycle. 


Uncontrolled  Non  -  Standard  Run  -Time  Environments 


The  demise  of  Che  mlllcary  computer  family  eventually  led  to  the  creation  of 
Che  Army  Command  and  Control  Common  Hardware  Software  (CHS)  System.  It  is  the 
PEO  CCS  charter  to  lay  Che  architecture  for  a  common  hardware /software  for 
each  of  the  functional  nodes  within  the  star  for  battlefield  command  and 
control  interoperability.  It  is  important  to  note  chat  this  architecture 
provides  the  standards  for  Army  CHS;  therefore,  the  entire  area  outside  of  the 
nodal  integration  has  no  direction  or  mandate  concerning  standardization  of 
computer  systems.  Thus,  the  creation  of  common  environments,  targets/hosts 
and  runtime  environments  is  non-existent  for  dx>sc  embedded  computer  systems. 
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Inconsistent  Approach  to  SQA 

Software  Quality  Assurance  (SQA)  responsibilities,  procedures,  and  authority 
within  MSCs  require  some  updating  and  more  complete  implementation.  Issues  of 
concern  include: 

(1)  Ensuring  that  transitioned  software  and  documentation  are  of  good 

quality 

(2)  Conducting  quality  inspections  of  computer  program  code  and 
documentation  to  ensure  supportabllity  of  the  delivered  software 
product 

(3)  Determining  what  life  cycle  phases  PA&T  should  support. 


Testing  Tools,  Measurable  Standards  Undefined 

LCSEC  test  and  validation  processes  lack  Che  comprehensive  and  disciplined 
oractices,  centrally  coordinated,  to  meet  mission  critical  requirements. 
Issues  of  concern  include: 

(1)  Developing  design  techniques  and  methodology  for  selecting/ 
developing  automated  test  cools 

(2)  L’sing  simulators  and  stimulators  to  a  greater  extent 

(3)  Adequately  reviewing  procedures  and  results 

(4)  Creating  integration  methodologies  that  include  rigorous  planning 
and  test  criteria 

(5)  Ensuring  responsible  organizational  levels  of  testing 

(6)  Controlling  a  proliferation  of  test  cools. 
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Non  -  Standard  Interfaces;  Lack  of  Test  Bed 

A  need  exists  to  establish  Army-wide  responsibility  and  authority  to  assure 
that  proposea  system  changes  do  not  adversely  Impact  the  interoperaoility  of 
existing  systems.  If  system  interoperability  is  a  specified  system 
requirement,  then  management  of  software  must  provide  a  mech  ilsm  for 
determining  whether  any  proposed  changes  will  disrupt  interoperations. 
Further,  a  mechanism  must  exist  for  analyzing  the  impact  of  Imposing  new 
interoperability  requirements  on  existing  systems.  In  order  to  maintain 
interoperability  among  fielded  systems,  installation  planning  for  MODS 
software  revisions  must  be  coordinated.  This  coordination  must  account  for 
revisions  affecting  inter-slta  compaclblllty  and  MCDSa  that  must  ba 
interoperable  with  ocher  and  different  MCOSs.  Policy  needs  to  be  established 
for  developing  new  tactical  data  links  and  for  maintaining  existing  data 
links.  The  Army  has  allowed  development  of  coo  many  uniquely  defined  data 
links  with  very  similar  overall  requirements  (ATDL-l,  MBDL,  Pstriot  DL,  FAAD 
C21  DL). 


Target  Hardware,  Media  Variety  Complicates  Support 

As  a  resulc  of  the  way  the  Army  let  its  contractors  select  the  hardware  which 
makes  up  Its  fielded  weapon  systems,  it  has  inherited  two  problems  which  add 
additional  unnecessary  complications  to  its  software  support  problems.  The 
wide  variety  of  target  processors  have  made  it  virtually  impossible  to 
establish  a  common  run  time  support  for  its  weapon  systems*  For  each  of  its 
field  systsms,  it  not  only  must  maintain  the  operational  software,  but  must 
maintain  the  elements  of  the  field  operating  system  on  which  the  operational 
software  runs.  The  lack  of  standard  I/O  devices  and  media  require  the 
continues  acquisition  and  support  of  a  variety  of  equipment  Just  to  provide 
software  fixes  and  replacements  to  the  field. 
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Poor  Execution  of  Replication,  Duplication  &  Control 

Because  each  system  is  being  developed  individually  under  separate  ?M  control, 
with  each  system  having  established  its  own  unique  methoa  or  software 
replication  and  distribution,  several  problems  result.  Current  practices  and 
procedures  in  this  area  make  inefficient  use  of  scarce  personnel  resources,  do 
not  allow  for  timely  replacement  of  failed  software/ firmware  (3W/FW),  and  do 
not  lend  themselves  to  a  timely  upgrade  of  systems  in  fielded  units.  Because 
there  is  no  common/central  configuration  control  point  for  the  fielded  SW/fW, 
the  probability  of  field  units  receiving  Incorrect  software  or  firmware  is 
Increased.  The  lack  of  central  control  and  a  standardized  methodology 
increase  the  problems  of  accountability  of  stock/replace sent  of 
sof tware/firmware  components.  Because  of  these  factors  and  the  lack  of  a 
prioritization  scV.me  based  upon  user  needs,  timely  replacement  of  failed 
wedla  is  difficult  or  impossible.  Some  systems  have  duplicate  software  media; 
others  have  the  ability  to  replicate  their  software  in  the  field,  still  others 
can  be  replicated  only  by  the  development  contractor  at  the  development  site. 


No  Effective  Configuration  Management  for  Software 

The  Aray  is  faced  with  lanaging  rapidly  changing  software  technologies  and  a 
aultlplicity  of  complex  hardware  and  software  systems  in  the  field-  The 
ever- ;nc reas i ng  costs  of  new  software  development  and  existing  system  life 
cycle  support  are  overstresslng  resources  and  could  threaten  the  combat 
readiness  of  the  L'S  Army.  Existing  CM  procedures  are  highly  coupled  to 
nareware  system  requirements.  These  directives  and  standards,  which  preceded 
new  Joint  Logistic  Cumsanders'  software  policies,  are  not  fully  responsive  to 
the  dynamic  needs  of  HCDS  software  development,  acquisition,  and  life  cycle 
support.  .\s  a  result,  there  is  lirt-le  comaonallty  In  the  way  differenc  MSCs 
lapleacnc  software  configuration  control.  AMC  (AMCOE-SB-C)  on  2  Oecember  1986 
issued  Commander's  Guidance  Statement  (CCS)  No.  155  for  MIssIod  Critical 
System  Software,  Battlefield  Automated  Software  Dcvtlopmanc.  Tula  guldaoca, 
which  lapiemcrittd  0o0-’ST0'’2 167  and  DoO*STD-1467,  waa  Incomplcta  with  raspacc 
to  software  comf Iguratlon  managemant  ttandarda  required  Co  support  aoftwara 
life  cyclu  support.  New  guidance  specifically  tailored  to  the  uolqua  software 
management  rsquireaents  is  a  praising  need. 


Software  'Components*  not  Adequately  Tested 

DoDD  5000.3  (Test  and  Evaluation)  is  the  authority  for  test  and  evaluation  in 
the  acquisition  of  defense  systems  and  also  provides  definitions  and 
guidelines  for  the  Test  and  Evaluation  Master  Plan  (TEMP).  The  Army's 
implementation  of  this  DoOD  is  AR  70-10  dated  30  April  1986.  DA  published  the 
LOSS  Implementation  Plan  dated  Dec  83  to  establish  a  strategy  for  Army-wide 
management  control  and  software  support  of  MCDSs.  The  plan  advocates  software 
testing  consistent  with  the  procedures  specified  in  the  Software  Quality 
Assurance  Plan  for  each  specific  system.  The  categories  of  testing  Included 
Certification  Testing,  Verification  and  Validation  (V&V)  Testing,  User 
Acceptance  Testing,  Development  Test  (DT)/0peratlonal  Test  (OT),  and 
Interoperability  Test.  Although  the  draft  Software  Test  and  Evaluation  Manual 
(DoD  3000.3-M-3)  provides  a  software  evaluation  guide  (Appendix  A)  and  a 
software  test  and  evaluation  plan  (Appendix  B),  It  does  not  present  specific 
guidelines  as  to  a  threshold  percentage  of  test  pass/fall  criteria, 
distinction  between  critical  requirement  function  tests  versus  non-crltlcal 
requirement  function  tests  and  their  relative  weights  In  determining  the 
pass/fall  criteria,  and  a  minimum  set  of  performance  function  tests  required 
for  acceptance. 
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Release 


Lack  of  Management  of  Software  Releases 

The  release  of  a  software  version  for  any  one  sysreo  Is  akin  co  che  iceberg 
analogy:  what  you  dor ' c  see  ere  Che  problems  associated  with  inadequate 

testing,  interoperability,  documentation  for  the  field  user,  and  cvalucion  of 
compliance  with  Che  user's  requirements.  Changing  software  in  any  system  is 
Che  responsibility  of  che  material  developer,  but  Che  responsibility  of 
validating  che  requirements  rests  with  che  combat  developer.  For  hardware 
releases,  there  is  a  standard,  well~exerclsed  process  which  ensures  that  all 
concerns  have  been  addressed  prior  to  release.  Current  policies  call  for  this 
formal  material  release  process  co  be  followed  for  all  "■ajor”  software 
releases.  Unfortunately,  some  MSCs  have  classified  very  few  of  their  sefeware 
changes  as  major,  and  therefore  they  have  not  been  released  trough  che  formal 
process.  The  ambljulty  In  current  material  release  regulations  needs  to  be 
removed.  It  should  be  che  rule  rather  chan  che  exception  to  review  software 
releases,  and  che  process  needs  to  account  tor  che  peculiarities  of  software 
Including  Interoperability  certification  . 


Poor  Consideration  of  Interoperability 

While  general  cescing  principles  apply,  interoperability  testing  is  unique 
from  other  foms  of  testing  in  that  two  or  more  systems  are  required.  While 
certain  aspects  of  interoperability  may  be  tested  in  a  stand-alone  system 
(e.g.,  ability  to  send  and  receive  messages  using  specified  protocols),  true 
interoperability  testing  is  complex  and  necessitates  a  special  approach  in 
formulating  test  requirements  and  test  capabilities.  Use  of  an 
interoperability  test  capability  is  required  to  validate  system  interfaces  and 
interoperability  requirements.  This  is  a  major  issue  that  encompasses  pre- 
and  post-fielding.  Prior  to  fielding,  major  systems  must  be  tested  to  assure 
chat  they  will  interoperate  properly  in  the  field.  This  methodology  has  not 
been  Implemented  and  there  are  serious  concerns  about  whether  it  can  be 
implemented  properly  in  the  near  future  without  an  integrated  interoperability 
testing  capability  as  more  new  systems  arc  fielded  and  interoperability 
requirements  become  more  complex. 


Lack  of  interoperability  Test  Bed 


After  fielding,  the  system  users  need  to  be  able  to  discern  the  cause  or  basis 
of  a  system  failure.  The  question  of  which  system  is  at  fault  is  not  a 
trivial  one  to  answer.  The  system  engineering  talent  is  not  available  in  the 
field,  anemic  is  not  clear  to  the  user  as  to  whoa  should  be  called.  An 
Interoperability  test  bed  would  provide  the  required  capability  to  validate 
interfaces,  resolve  cross  system  difficulties,  and  detsralne  which  agency  is 
responsible  for  correcting  interface  problems. 


A#  »  la 


A  mm 


•  >  m  ^  ^ 


Lack  of  Interoperability  Test  Bed 

A  great  value  iahereaC  with  software  today  Is  the  ease  of  making  a  rapid 
change  (enhancement)  tc  a  system  in  response  to  a  requirement  change( threat) • 
For  this  to  happen  a  support  system  must  ensure  the  following: 
interoperability  consi^ration  and  a  means  to  react  in  a  timely  manner.  Both 
of  these  requirements  are  difficult  to  meet  if  standard  Army  systems  are  used. 
The  interoperability  problem  has  already  been  discussed;  timeliness  has  not  • 
Pushing  fixes  through  the  hardware  supply  system  and  not  effectively  be  used 
to  get  emergency  fixes  to  the  field.  When  Interoperability  is  needed,  the 
supply  system  will  not  work  at  all  when  interoperating  systems  must  Implement 
new  software  simultaneously.  This  thwarts  the  whole  benefit  of  the  software's 
ability  to  effect  a  quick  fix. 


Untimely  Response  to  Field  Problems 

Although  there  is  a  Quality  Deficiency  Report/Equipment  Incident  Report 
(QUR/EIR)  Reporting  System,  it  has  not  been  modified  to  incorporate  software 
aef iciencies .  This,  coupled  with  the  ever  present  problem  of  identifying 
software  vs.  hardware  troubles,  can  result  in  delays  in  fixing  problems. 
There  is  no  easy  way  to  craclt  computer  deficiencies  through  the  QDR/EIR 
system.  DA  PAIi  738-7  50  does  not  have  a  code  that  describes  a  problem 
associated  with  computer  hardware/software.  The  embedded  computer  mission 
critical  defense  systems  deployed  or  near  deployment  to  Amy  field  users 
employ  numerous  types  and  variations  of  media  manufactured  to  load  operational 
software  into  the  Individual  system.  To  date  no  affective  effort  has  been 
applied  by  AMC  to  standardize  on  a  limited  set  of  such  media.  The  result  is 
that  a  unique  production  cape  replication  facility  is  required  for  virtually 
every  system.  For  example,  one  cartridge  utilized  cor  five  Army  systems  has  a 
unit  cost  of  $500-600,  yet  Inspeccton  of  the  cartridge  indicates  little  basic 
technological  difference  with  respect  to  VUS  tape  cassettes,  which  sell  for 
one  percent  of  the  cost.  The  difference  is  volume.  The  Amy  is  procuring 
their  own  cartridges  in  quantities  of  thousands  per  year  while  VHS  cartridges 
are  being  manufactured  and  purchased  in  quantities  of  millions  per  year. 


Uneven  Usage  of  Area  Software  Analysts 

Opirators  and  maincenance  personnel  are  not  trained  to  detect  and  verify 
software  problems  within  an  embedded  system.  MSCs  attempted  to  fix  this 
problem  with  the  creation  of  Area  Software  Analysts.  The  ASA  does  not  work 

under  the  direction  of  the  LCSECs,  but  Is  assigned  to  the  Readiness  side  of 

% 

each  MSC  as  are  the  LARs.  There  is  no  process  or  training  for  the  ASAs  to 
familiarize  themselves  with  the  embedded  systems  they  must  support.  Their 
best  effort  is  to  "possibly"  identify  a  software  problem  and  report  It  to  the 
appropriate  LCSEC,  although  in  most  Instances  the  user.  If  knowledgeable  of 
Che  LCSEC,  will  report  Che  problem  directly. 


Single  Face 


PMs,  LCSECs  Each  Need  to  Deal  Directly  with  User 

Since  Che  first  PAS  was  introduced  to  the  field  there  has  never  been  an 
approved,  funded  plan  to  establish  AMC  forward  LCSEC  offices  in  OCON'US.  The 
result  of  this  has  dictated  the  requirement  for  a  new  software  team  each  time 
a  version  is  released  to  the  field  to  ensure  successful  installaclon  and 
operator  training.  In  many  cases,  there  are  no  standard  ur  coauaon  methods  for 
training  either  the  field  users  or  the  software  field  support  personnel.  The 
situation  is  further  complicated  by  Che  replication  and  distrlbutiou  methods 
being  as  diverse  as  the  systems  themselves.  Some  efforts  by  organizations 
such  as  PA&T,  LCSECs,  and  ORE,  appear  to  be  redundant,  which  causes 
inefficient  utilization  of  an  already  critically  small  pool  of  experienced 
psrsonnel.  The  overall  system  level  analysis,  evaluation  process,  and  the 
preparation  of  the  ancillary  support  packages/ functions  are  difficult  to 
implement  in  a  timely  and  coordinated  manner,  which  causes  additional  problems 
in  distribution  of  complete  system  peerages  to  the  field  users.  Documentation 
and/or  training,  for  example,  frequently  Isgs  Che  delivery  of  Che  actual 
software  media. 
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Little  Investment  in  Tools,  Reuse 

A  Strategy  for  developing  a  program  that  will  Identify  the  dollars  for 
investing  in  standard  environ'^ents  and  compatible  tools  is  still  a  long  way 
off.  This  has  been  stymied  because  there  is  no  focal  point  at  the  DA  level 
that  has  the  where-with-all  for  planning  software  technology.  Evidence  of 
policy  or  regulations  that  support  definition  of  a  strategy  is  absent; 
therefore,  software  domain  needs  are  not  considered.  Standards  and 
methodologies  for  software  architecture  should  include  procedures  for  creating 
portable  and  reusable  software.  Here  again,  there  is  no  directive  or 
regulation  to  establish  a  mechanism/ organization  chat  would  be  responsible  for 
one-time  developed  and  reusable  software  cools. 
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Incompatible  Tools;  No  Agreed  Upon  Methodology 

Because  chere  is  no  agreed  upon  methodology,  there  lacks  the  means  to  answer 
many  important  -questions: 

(1)  How  can  generic  requirements  be  established? 

(2)  How  can  one  Identify  and  develop/ procure  common  software  vlth  reuse 

as  a  goal? 

(3)  What  standards  apply  to  test? 

(4)  What  will  be  the  incentives  to  the  contractor  for  reuse  and  pass 

off  of  cool  development? 

(5)  Would  chere  be  enough  cosmon  software  Identifiable  to  Justify  the 

cost? 

There  has  been  little  or  no  consideration  given  to  planning  for  a  software 
development  or  support  environments  so  that  a  suite  of  compatible, 
complementary  tools  were  acquired.  Rather  chan  acquiring  Individual  packages 
suitable  for  their  own  Individual  purpose,  Identifying  Cools  capable  of  being 
Integrated  with  others  for  greater  effectiveness  should  have  been  the 
direction  taken. 
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Software  Concerns  Addressed  as  an  Afterthought 

MCLS  procuremeac  strategy  in  the  past  has  Involved  the  prime  contractor 
approach.  The  contractor  develops  Che  software  from  scratch  and  may  employ 
proprietary  software  cools,  and  in  Che  worst  case,  tse  an  unapproved  KOL. 
During  negotiations,  Che  contractor  will  resist  the  applicable  military 
standards  and  use  cost  and  schedule  impact  as  an  argument  to  reduce  the  scope 
of  software  documentation  deliverables  and  other  administrative  and/or 
management-type  responsibilities.  The  result  is  that  the  eventual  fielded 
system  software  is  difficult  to  support.  Documentacloo  may  be  inadequate, 
often  inaccurate,  and  can  be  in  contractor-unique  format.  Reusable  and 
transportable  software  will  not  have  been  addressed.  Support  may  eventually 
require  a  sole  source  contract,  back  to  the  system  prime  contractor,  and  the 
adverse  process  continues. 
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Failure  to  Address  Data  Rights.  Liability,  Warranty 

H  aew  approach  Is  required  In  procureaent  practices,  which  taay  require 
substantial  contract  Incentives,  to  encourage  positive  response  to  AcU , 
interoperability,  N'DI,  and  comnonallty  ‘n  software  requlieiaents .  To  be 
successful,  these  contracting  practices  will  have  to  be  coupled  with  complete 
comollance  to  new  specifications  and  standards.  Because  of  some  of  these 
difficulties  Inherent  In  Che  acquisition  of  software,  we  have  failed  to 
provide  definitive  guidance  to  address  critical  questions: 

(1)  What  level  of  government  data  rights  is  required  for  each 

individual  procurement? 

(2)  Vhen  is  the  optimal  time  to  acquire  data  rights,  if  any? 

(3)  What  is  Che  proprietary  right  when  one  contractor  develops  cools 
and  another  contractor  maintains? 

(4)  What  derived  right  does  slightly  modified  software  resold  by  e 

contractor  to  another  buyer  at  a  fraction  of  cost  have? 

(5)  Who  is  liable  for  software  chat  contributed  to  a  human  death? 

(6)  For  what  time  frame  should  warranties  be  required  to  ensure  that 
cachnicsl  def i.ciencies  will  be  corrected? 

(7)  What  is  Che  original  developer's  responsibility  (warranty)  if  a 

second  contractor  performs  enhancements? 

(8)  What  is  covered  in  a  warranty,  and  how  can  all  implications  be 

anclclpaced? 

(9)  Will  warranties  Induce  great  quality  of  software? 


No  Software  Technology  Program 

There  is  luch  written  and  taught  concerning  the  discipline  of  software 
engineering;  however,  the  actual  practice  is  still  in  the  infantile  stage. 
The  evolution  of  software  engineering  as  a  disciplined  science  has  only 
eaergad  in  tne  last  decade,  yet  the  computer  has  been*  in  existence  for  over 
half  a  century.  Software  technology  has  typically  found  its  way  In  the 
unstructured  cottage  industry,  unlike  the  directed  research  of  electronic 
(hardware)  technology  that  has  been  a  highly  disciplined,  standardized 
science.  The  nature  of  this  evolution  lead  professionals  to  continually 
reinvent  the  "software  wheel’  without  taking  the  time  (and  resources)  to 
instill  a  discipline  into  the  science.  Another  phenomenon  of  the  ’wizarlry 
art"  of  software  was  the  incredible  momentum  that  propelled  its  technology 
explosion.  While  this  explosion  of  software  technology  enabled  man  to  walk  on 
the  moon,  it  was  not  harnessed  to  Instill  discipline  toward  a  productive  end. 
This  rapid  change  also  made  it  difficult  to  set  standards  and  policy  in  place 
because  there  simply  were  no  developed  skills  to  begin  technical  management. 
However,  approach  to  maturing  software  technology  areas,  planning  for  and 
implementing  advancing  technologies  will  be  fragmented,  haphazard,  and 
ineffective. 


\  People 


Policy 


Process 


Procedure  Strategy 

Planning  ^  TechnoloQv 

Insertion 


Evoluflon 

Quality 


No  Concern  with  High  Performance  Systems 

cjntracccrs  have  SLiCcesst ally  been  building  large  software  sysceas 
:-r  soae  time,  quantum  leaps  in  the  s'bhistltation  and  coaplexity  of  eaerging 
systems  r.ave  plated  new  and  acre  rigid  requirements  an  their  aevelcpment 
methodologies,  design  considerations,  and  implemenLatlon  processes.  In 
particular,  high  performance  reauirements  such  as  increased  reliability,  real* 
time  operations,  and  the  handling  fusion  of  huge  amounts  of  data  have  stressed 
contractors'  ability  to  produce  systems  capable  of  functioning  for  prolonged 
periods  under  battlefield  conditions.  We  have  further  compounded  our  problems 
by  virtually  ignoring  Interoperability  issues  during  systems'  concept  and 
early  development  phases,  consequently  fielding  systems  that  perform 
adequately  in  s  discrete  envrlonment,  but  cs..inot  meet  the  high  performance 
requirements  of  an  Integrated  battlefield. 


Failure  to  Bring  Discipline  to  Software  Management 

Failure  to  insert  discipline  into  the  software  aianagement  process  failed 
through  the  lack  of  standards  and  a  viable  methodology  that  inevitably  leaos 
to  adverse  impacts  on  performance,  cost,  schedule,  and  supportability •  This 
led  to  such  a  dynamic  fiscal  program  that  only  the  best  software  management 
"wizard”  was  skilled  in  defending  development  and  sustainment  costs,  since 
there  were  no  realistic  criteria  for  software  program  planning.  Past 
relationships  of  the  PM's  with  software  support  centers  has  been  based  on 
system  specific  agreements  instead  of  sound  software  management  and  control 
practices.  This  was  all  the  result  of  splintering  software  life  cycle 
activities  without  providing  adequate  authority  and  coomunlcatlon  to  Integrate 
a  systems  approach  into  software  development.  The  management  of  a  system 
(BAS)  has  not  included  the  significance  of  software  la  cost  or  quality  as  a 
standardize  definable  process. 


Software  Quality  Frequently  Traded  -  Off 

Systems  are  developed  today,  and  yet  there  Is  no  universal  measure  of  software 
quality.  With  all  the  emphasis  placed  on  developing  quality  software, 
effectively  measuring  It  is  still  uncertain.  However,  what  little  is  known 
about  developing  quality  software  usually  Is  not  written  Into  the  contract 
specifications  or  Is  degraded  because  of  schedule,  cost,  or  quality  tradeoffs. 
All  of  this  results  from  the  absence  of  a  standard  development  methodology 
that  desperately  needs  engineering  discipline.  Because  there  is  no  measure 
for  accessing  the  quality  of  software,  quality  will  always  be  a  function  of 
the  caliber  of  the  people  developing  It. 


Failure  to  Maintain  Software  Knowledge  Base 

Altnough  software  Is  a  critical  element  in  our  continued  ability  to  develop 
advanced  weapons  systems,  we  have  failed  to  recognize,  arid  to  provide 
sufficient  means  and  inc<»ntives,  to  foster  the  growth  of  a  software  knowledge 
base  in  our  government  staffs.  This  problem  area  has  been  discussed  under 
training,  management,  awareness,  education,  and  career  path  issues,  and 
effects  both  government  and  civilian  and  military  personnel.  Without  the 
expertise  to  understand  software  technologies  and  to  effectively  oversee 
program  acquisitions,  no  level  of  financial  investment  will  return  to  us  the 
systems  capabilities  and  fighting  capabilities  winning  will  require. 
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Army  State  -  of  -  Practive  Far  BehirKf  State -of -the  -  Art 

«hy  Chen  Is  technology  not  Inserted  into  a  software  discipline  to  keep  state- 
of-practlce  in-line  with  state-of-the-art?  Training  of  software  engineers  is 
not  geared  toward  an  evolving  technology  and  its  growth  in  software  system 
complexity.  Training  must  orient  toward  a  "systems"  software  approach  and 
instill  the  Interdiscipline  of  a  software  engineering  methodology.  Training 
is  only  one  part  to  solving  the  puzzle  since  quality  productivity  is  a  key 
missing  piece.  Productivity  translates  to  a  lack  of  standard  tools  and 
techniques  to  reduce  development  and  training  costs.  Right  now  there  is  no 
incentive  for  developing  these  tools  and  maintaining  research  facilities 

because  the  cost  is  viewed  as  coo  great.  It  is  difficult  to  conduct  a  trade 
off  analysis  of  improved  productivity  versus  the  coat  of  developing  new  cools 
and  better  training.  If  there  is  not  a  concentrated  effort  to  place  the 

dollars  up  front  iu  research  and  initial  development  then  a  far  greater  cost 
will  result.  This  adverse  cycle  has  been  experienced  tima  and  time  again,  yet 

only  now  is  the  DoD  waking  up  to  the  high  fiscal  reality  of  it  all. 


People 


Policy 


Process 


Procedure  \  Strategy 


Planning 


Technology 


Insertion 


Knowledge 

Behind  SOA 
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APPENDIX  B 


Recommended  Actions 


"In  the  design  of  automobiles,  the  knowledge  that  you  can  design 
the  motor  more  or  less  independently  of  the  wheels  Is  an  Important 
Insight,  an  important  part  of  an  automobile  designer's  trade.  In  our 
field,  if  there  are  a  few  specific  things  to  be  produced ...  It  would  be 
very  Important  to  decide  what  are  their  parts  and  what  is  the  proper 
sequence  of  deciding  on  their  parts." 

Peter  Naur 

NATO  Science  Committee 
conference  on  Software  Engineering 

October7-11,1968 


SS-111 

Implement  an  Effective  Software  R&O  Strategy 


The  Army  must  recognize  that,  because  of  the  growth  of  the  commercial 
software  market,  it  needs  to  be  primarily  a  buyer  rather  than  a 
builder  of  technology  for  software  development.  The  Army  strategy 
for  software  technology  should  be  built  upon  the  industry  standards 
and  use  of  commercial  tools  whenever  possible.  However,  in  those 
areas  where  special  Army  needs  exist,  the  Army  needs  to  pursue  an 
aggressive,  focused  R3iD  program. 


RECOyMENDATIONS: 

A.  Develop  a  Software  Technology  Plan 

-  Identify  pacing  technology  issues 

-  Define  areas  where  technology  crucial  to  Army  needs 

•>  Shew  areas  where  industry/government  agencies  will  focus  efforts 

B.  Establish  a  testbed  to  evaluate  commercial  products 

C.  Evaluate  oommarcial  products/standards  for  Army  applicability  • 

O.  Structure  R&O  program  with  reuse  as  a  keystone 

-  Application  Software 

-  Tool  selection  and  use  among  projects 

-  Public  domala  non  -  proprietary  products 

E.  Conduct  research  to  satisfy  specific  unfulfilled  Army  need 

-  Softeere  Reuse 
-Metrics 

-  More  productive  Software  Paradigms 

-  Others  to  be  defined,  e.g. 

-  -  Prototyping  A  Formal  Speciticatlon 
—  Requirernents/Docirneritatlori/Uto  Processes 
—  DfetJibutedCornputlng/Real-TirnePerlbmwce 
—  Application  of  AdaToois  &  Methodology 

F.  Structure  Irvaentlvec  to  Increaae  Compatible  Industry  Software  IR&D 
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Develop  an  Approach  to  Software  Reuse 


A  consistent  approach  to  software  reuse  must  be  developed. 
Implementing  effective  software  reuse  procedures  will  result  in  cost 
savings,  improved  quality,  and  reduced  development  time.  The 
approach  must  be  built  on  the  recognition  that  it  will  take  at  least 
ten  years  for  reuse  technology  to  mature.  Initial  efforts  will  employ 
reusable  software  artifacts,  follow  -  on  efforts  will  improve  ways  to 
adapt  existing  systems.  In  the  final  phase,  reuse  will  be  a  function 
of  the  tools  used  to  generate  new  systems. 

RECOyMENQATIONS: 

A.  Develop  a  plan  to  acquire  reuscuie  software 

-  Public  domain,  non  -  proprietary  software 

-  Based  on  Industry  standards 

-  Uoense  commercially  available  software 

B.  Establish  a  software  reuse  R&D  program 

-  Build  on  current  constructive  approaches 

—  ClasssficatJon  and  Retrieval  Systems 

-  -  KroAtedge-basadtools 

—  Design  and  coding  standards  for  reuse 

-  -  CreattoiVmaintenanceof  library  of  "certified  parts" 

—  Techniques  to  make  artifacts  more  general  and  flexible 

-  Investigate  use  of  generative  systems 

—  Near  term  emphasis  on  application  generators 

—  Long  term  emphasison  template/transformation  systems 

—  Emphasize  approaches  using  domain/prooess  knowledge 

C.  Investigate  non -technical  issues 

-  Develcpment  of  standards 

-  Data  rights,  warranties,  and  liability 
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Develop  and  Evaluate  Software  Metrics 


Process  and  product  oriented  metrics  need  to  be  defined  and 
evaluated.  Tools  which  support  useful  metrics  should  be  integrated 
Into  software  environments  used  to  develop  and  support  Army 
software.  Quantitative  measures  of  contractor  performarxse  and 
product  suitability  are  needed  to  ensure  succe^ul  management  of 
the  software  process. 


RECOMyENDATIONS: 

A.  Collect  and  uae  existing  compiler  perfortnanoe  metiics 

B.  Establish  frarnework  to  evaluate  metrlca  for  applications 

-  Idcrrttfy  metrics  with  high  potential  for  use 

-  Capitalize  on  existing  effort  to  Identity  tools 

-  Use  data  from  DACS/RAOC  database  where  appllcabie 

C.  Callirata  axteting  metrics  with  ongoing  programs 

-  Process  and  Management  Indicators 

-  Product  Design  and  Build  Attributes 

-  Peribfmanoe  Indicators 

D.  Develop  and  evaluste  new  product/prooess  metrics 

-  Map  metrics  to  Important  decision  factors 

-  Identify  immature  measures  or  those  based  on  invalid  assumptions 

-  EvaiualB  evolving  practices  and  products 


SS-114 

Evaluate  Software  Life  Cycle  Models 


Software  technology  is  an  immature,  rapidly  evolving  technical 
field.  Dramatic  growth  in  complexity  and  size  of  Army  sot^vare 
systems  requires  the  Army  to  foster  and  direct  the  evolution  of 
new  practices,  procedures,  and  methods  for  the  development 
of  software  systems. 


RECOMMENDATIONS: 

A.  Develop  model  to  select  paradigm  and  evaluate  payoffs 

-  Sequenttai  or  waterfall  model  for  well  -  defined  requirements 

—  Needs  more  intensive  up  -  front  planning  of  interactions 

-  -  Morecomprehensivedocunnentation  required 

—  Win  reduce  cost  if  requirements  are  complete  at  start 

-  Rapid  Prototype  and  Iterative  Development 

—  Best  to  use  when  user  requirements  must  be  refined 
—  ANows  user  to  provide  feedback  with  use  of  prototype 

-  Incremental  Deveiopmeiit 

—  RequiremerTts  are  understood  but  user  needs  quick  initial  fielding 

-  -  Functicnality  and  performance  are  slowly  integrated 

B.  Investigate  alternative  paradigms 

-  Automation  based 

-  Reuse  Based 

-  Risk  Management  based 

C.  Improve  specificatton  oorractness^completeness  analysis  methods 

-  Fonrial  Specification 

-  Automated  Documentation  Production 

D.  Investigate  other  supporting  technologies 

-  Methods  to  better  oommunicate/affirm  requirements 

-  Methodologies  for  very  large  systems 

-  Considerations  for  distributed  systems 
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Establish  Controls  on  Software  Environments 


The  Army  must  develop  a  viable  approach  to  the  management  of 
software  engineering  environments  it  uses  or  permits  to  be  used 
for  MCCR  development  and  support.  Initiative  and  productivity  of 
developing  coniractors  needs  to  be  encouraged,  yet  the  Army  must 
ensure  that  systems  are  supportable,  in  -  house  scftvi'are  support 
environments  need  to  be  standardized  to  achieve  economies  of  scale, 
improve  resource  efficiencies,  allow  more  rapid  transition  to  a 
support  posture,  and  improve  productivity  and  quality. 

RECOyMENDATIONS: 

A.  Esiabiteh  iwfutramentB  and  standards  for  ctovalopers 

-  Effective  support  for  Ada  language 

-  Minimum  toolset  capabilities  tailored  to  system  type 

-  Contractor  unique  tools  meet  data  representatlon/interfaoe  standards 

-  Use  of  spedfted  run  •>  time  environments  on  target  computers 

B.  Develop  requirements  for  extensible  Army  support  environment 

-  Army  should  buy  instead  of  build  tools  wherever  possible 

-  Use  non -pfoprietarystaridards  to  form  frarn^'/ork  of  system 

--PO^baead 

-  -  Ada  language  standard 

—  Design,  intarmediate  representations 

-  Complete  suite  of  life  cycle  tools 

—  Prototyping  and  design  tools 

—  Product  and  process  metrics 

—  Support  tor  hosVtarget  analysis  and  debugging 

-  Selected  standard  tools  across  all  environment  Instantiations 

—  Problem  reporting,  configuration  management.  ... 

-  -  Contractors  either  use  same  tools  or  convert  data  upon  delivery 

->  Insert  eseential  development  tools 

—  Acquire  wtth  limited  data  rights 

—  Enoourage  developing  contractors  to  use  best  technology 

C.  Constrain  target  machines  to  meet  Army  needs,  reduce  cost 

-  Standard  battlefield  hardware 

-  CorTvnerclaily  derived  tomily  of  run  -  time  operating  systems 
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Manage  the  Introduction  of  Ada  into  the  Army 


Ada  Introduction  plans  and  activities  need  to  be  strengthened  If  the 
efficiencies  and  economies  of  Ada  are  to  be  achieved.  The  use  of 
Ada  will  reduce  the  number  of  tools  required  In  the  Army's  support 
environment,  improve  productivity,  and  increase  quality  of  software 
prod'jced.  No  Army  strategy  for  the  control  of  Ada  and  Its  introduction 
has  been  evident.  An  effective  and  purposeful  approach  is  needed. 


RECOMMENDATiry  i: 

A.  Fund  an  Army  supplement  to  the  OSD  ATIP  prograni 

-  Technology  Demonstration 

-  Lessons  learned  database 

-  increased  technical  confidence 

B.  Evaluate  efficiency  and  utilfty  of  commercially  available  tools 

—  Ccmpllers 

-  Program  Design  Language  support 

-  Syntax  Based  Editors 

“  Dynamic  debugging  tools 

-  Code  Review  and  Assessment 

C.  OovalopoompleteAdatralningprogram  within  Army 

-  Ada  tor  Project  Managers 

-  Ada  contracting  concerns 

-  Design  and  development  using  Ada 

D.  EvaluBte  success  of  Ada  Insertion 

-  Cost  impacts  on  programs 

-  Arelydsof  product  quality  implications 
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Establish  mechanism  for  Reverse  Engineering 


Standards  for  computer  resources  including  software  lanaguges, 
hardware  design,  documentation,  and  configuration  control  have 
evolved  since  Its  first  application  to  weapon  systems,  in  addition, 
many  existing  systems  were  developed  in  a  schedule  driven, 
resource  constrained  environment.  Because  of  these  factors,  the 
Army  must  recognize  the  need  to  use  reverse  engineering  to 
understand  system  design  from  existing  software  and  documentation. 

RECX>MMEN0AT1ONS: 

A.  Address  need  for  reverse  engineerirtg  In  pisnning  support 

-  Delermire  If  cost  effective  to  support  in --houss 

-  Plan  on  decreasing  sustainment  levels  as  system  matures 

-  Identify  specific  tasks  tor  each  system 

B.  Establish  crtterls  for  level  of  reverse  onginearing 

-  Anttdpated  extensive  software  modIfIcatJons 
Extraordinarily  high  number  of  software  deficiendes 

-  Ptenned  intensive  hardware  improvements 

-  Planned  replacement  date 

-  Evdutkyi  to  common  hardware/software  systems 

C.  Investigate  use  of  evolving  technology  to  assist 

-  T rartsJtlon  ongoing  high  risk  areas  to  Ada 

-  Testautomatic  derivation  of  design  from  existing  code 

-  Reooverknowtedge- base  as  design  Is  redeveloped 
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Develop  a  Strategy  for  Technology  Insertion 


The  Army  rntBit  improve  its  software  stale  -  of  -  the  -  practice  to  meet 
the  [feeds  of  the  large  and  complex  mission  critical  computer 
systems  of  the  future.  These  Improvements  must  be  promulgated 
within  the  legal,  fiscal,  and  contractual  constraints  of  the  government 
and  reduce  the  risk  to  system  development  accruing  from  thie  use 
of  unproven  technologies. 


RECOMyENOATlONS: 

A.  identify  specific  rtek  management  f uncte  for  software 

B.  Fund  parallel  duvetopments  when  introducing  new  technology 

C.  Provide  contract  award  for  successful  technology  application  to 

-  Improve  productfvtty 

-  Improve  quality 

D.  Establish  transition  points  and  mechanisms 

-  Software  Technology  Center  as  technology  advocate 

-  Consider  technology  insertion  in  computer  resource  planning 

E.  Develop  techniques  for  Software  Process  Improvement 

-  Software  Acquisition  in  a  Hardware  NDI  Environment 

-  Management  of  Firmware  as  if  it  were  Software 

-  AasignmerTtof  Data  Rights 

-  Stnxturing  of  Realistic  Software  Incentives 

-  Streamlining  of  Documentation  Requirements 

-  Clear  Communication  of  User  Requirements 

-  -  Fdirnal,  Executable  Language  for  Prototypes 
—  Language  Understood  by  User,  Buyer,  and  Builder 
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Conduct  Integrated  Software  Planning 


CRMPs  do  not  serve  their  Intended  function  as  currently  prepared 
because  they  do  not  address  critical  issues  and  are  not  integrated 
Into  the  system  acquisition  planning  process.  Planning  for  software 
must  be  addressed  irom  the  total  life  cycle  viewpoint,  with  proper 
attention  being  given  not  only  to  initial  development,  but  also  to  the 
critical  aspects  of  software  maintenance  and  Improvement. 


RECOMMENDATIONS: 

A.  Streamline  Computer  Resource  Menegement  Plan 

-  Limit  size  of  document;  remove  extraneous  and  redurxiant  data 

-  Make  CfiMP  pert  of  Acquisition  Strategy 

-  Define  all  computer  resource  arxj  funding  requirements 

>  Define  HarcMere^Softwtire  Acquisition  and  Support  Strategy 

B.  Computer  Reeouroe  Working  Group  provides  forum  for  PM 

>  Indude  LCSEC,  testers,  evaluators 

-  Provide  early  visibility  into  system  strategy 

C.  CRMP  documents  oondntons  of  oventuel  software  support 

-  PM  Identifies  resources  to  be  programmed 

-  LCSEC  guarantees  ability  to  support  If  strategy  executed 

D.  ApprovM  of  CRMP  by  PEO/AAE  retiflee  etrategy 

-  MACOMs  provide  body  of  experts  to  advise  PEG 

-  Feedback  on  effect  of  decision  provided  to  AAE 


SS-133 

Tailor  Software  Acquisition  Process  to  Systems 


The  Army  needs  to  encourage  the  use  of  alternative  software' 
development  models  rather  than  the  rote  application  of  existing  standards. 

^The  vast  differences  in  the  software  that  the  Army  buys  as  well  as  the 
limits  of  the  "waterfall  model"  must  be  recognized  and  deliberate  steps 
taken  to  reduce  acquisition  risk.  Procedures  are  needed  to:  refine 
requirements  prior  to  design,  strengthen  the  design  process,  emphasize 
"software  first,"  clarify  design  parameters,  and  improve  the  user/developer 
interface. 

RECX)MMENDAT10NS: 

A.  Esiablisfi  multi  -  axis  aa;ulsition  classification  scheme.  Including 

-  Degree  of  experience  v  ith  similar  systems 

-  Size  of  system 

-  Sensitivity  of  system  to  doctrinal  change 

B.  Define  candidate  strategies  for  different  system  classifications 

-  Life  Cycle  Model 

-  Software  Environment  acquisition  strategy 

-  Requirement  stability 

-  Software  Reuse  Potential 

-  Contract  and  Support  strategy 

-  Evaluation  strategy 

C.  PMs  classify  systems  and  use  classification  to  structure  acquisition 

D.  Ensure  risk  areas  addressed  before  Full  Scale  Development 

-  Prototype  hardvvare/software  design 

-  T race  design  back  to  users  requirements 

-  Base  decisions  on  timing,  storage,  performance  measurements 
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Develop  a  Consistent  Contracting  Approach 


All  too  often,  software  received  late  consideration  in  the  contracting 
process.  The  time  to  establish  specific  requirements,  get  contractor 
commitments,  and  ensure  adequate  resource  allocations  is  prior  to 
contract  award.  Procedures  need  to  be  established  to  reward 
competent  contractors,  force  an  early  consideration  of  development 
plans,  and  negotiate  effectively  for  software  consideration  during 
de/eiopment. 


RECOMMENDATIONS: 

A.  Address  softemre  in  proposal  preparation  instructions 

-  Provide  software  plans  as  part  of  technical  approach 

-  Define  specific  government  requirements  in  SOW 

-  Implement  plan  in  proposal;  do  not  buy  as  DID 

B.  Evaluate  oontractor  softvvare  maturity  In  source  selection 

-  Detailed  evaluation  of  SEI  process  model  by  gov’t  experts 

-  Establish  level  below  which  contractor  considered  non  -  responsive 

C.  Incorporate  software  performance  as  part  of  MACOM  database 

-  Evaluate  Contractor’s  past  Performance 

—  Previous  Sof^/va^BDeveloprT1e^ts 
-  -  Dedication  to  Total  Quality  Management 

-  Include  Information  In  Ongoing  AMC  Database  Development 

"Evaluation  of  Contractor  Past  Performance  In  Source  Selection" 

-  Identity  “Blue  Ribbon"  Software  Contractors 

—  Consider  in  Source  Selection 
—  Recognize  Outstanding  Performers 
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Organize  Army  to  Manage  Acquisition  Process 


Make  realignment  on  Army  staff  to  provide  effective  Army  Acquisition 
Executive  control  over  the  acquisitton  of  Army  systems,  especially 
those  which  rely  on  mission  altical  computer  resources.  Clear 
management  control  is  needed  to:  improve  jnanagement  practices, 
unify  the  DA  staff  into  an  efficient  structure,  and  develop  a  credible 
advocate  for  computer  resources  to  Congress  and  the  national 
leadership. 


RECOMMENDATIONS: 

A.  Eliminate  bicanieral  MCCR  management  at  HQDA 

-  Establish  full  -  time  Acquisition  Exectuive  for  Army 

-  Consolidate  Acquisition  Management  In  Single  Organization 

-  Focus  MCCR  Poilcy  In  Acquisition  Office 

-  Establish  Expertise  In  Real  -  Time,  Command&Control  Systems 

B.  CorrectAR  70-1  so  it  applies  to  Information  handling  systema 

-  Define  Applicabirrty  lAW  Chapter  8  of  AR  70  - 1 

-  CorrectAR  25  - 1  so  It  Excludes  MCCR 
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Improve  PM/PEO  Computer  Resource  Management 


Establish  an  effective  working  relationship  with  closer  cooperation 
between  the  PM/PEO  and  their  supporting  MACOMs.  The  present 
system,  which  has  given  PEOs  a  (Dercelved  independence  from 
MACOM  policy  and  guidance,  must  be  changed  if  weapon  system 
software  management  is  to  be  improved. 


RECOyMENDATIONS: 

A.  Dual  hat  functional  commanders  as  Program  Executive  Officers 

B.  Create  CRWG  early  to  identify  problems  In  CRMP  building 

-  Append  minutes  of  CRWG  meetings  to  CRMP 

-  Include  other  services  on  Inter-  Service  Systems 

-  Establish  CRWG  prior  to  Milestone  I 

C.  Use  CRMP  as  sole  basis  for  computer  resource  strategy  decisions 

-  Eliminate  duplicative  walver/approval  Processes 

D.  AAE  establish  process  to  stop  systems  erith  ill -conoeived  CRMP 

-  PM  certifies  no  embedded  Computers  used  It  no  CRMP 

-  Requira/Revlew/Approve  CRMP  prior  to  each  Milestone  Dedsioo 

E.  Hold  LCSE  directors  responsible  for  raising  planning  deficiencies 

F.  Use  "contracting  authority”  as  required 

-  Structure  RFP  to  acquire  Software  Intelligently 

-  Influnce  Source  Selection  process  to  consider  Software 

-  Prevent  awards,  it  neoessary,  If  process  goes  awry 

G.  Provide  experts  to  advise  PEO;  report  to  MACOM/AAE 
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Establish  Clear  Organizational  Responsibilities 


Provide  for  a  clear  understanding  of  organizational  responsibility 
at  all  levels  within  the  Army.  Changes  are  needed  to:  delineate  the 
roles  of  the  major  organizational  elements  In  the  area  of  computer 
resources,  implement  a  cost  effective  and  cohesive  organizational 
structure,  provide  clearer  lines  of  management  within  the  Army,  and 
prevent  duplication  of  effort  in  the  various  organizations. 


RECOyMENDATIONS: 

A.  Define  raleol  HQOA  in  overall  management 

-  Establishment  of  policy  objectives 

-  Advise  the  AAE  on  specific  acquisition  program  decisions 

-  Advocacy  for  resources 

B.  MACOMs  enforce  policy  and  define  strategy 

-  Maintain  body  of  expertise  to  assist  PM/PEO 

-  Identify  systemic  problems  and  provide  corrective  actions 

-  Promulgate  policy  based  on  lessons  learned 

-  Establish  procedures  for  consistent  Application  of  T echnology 

C.  lla|or  Sutxvdinate  Commands  support  acquisition 

-  Support  PM’s  acquisition  and  provide  field  support 

-  Evaluate  Ability  to  Provide  Support  for  Emerging  Systems 

-  Maintain  Infrastructure  to  Support  T ransitioned  Systems 

-  Execute  supporting  technologies  program,  as  assigned 
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Strengthen  AMC's  Software  Management  Role 


The  AMC  organization  needs  to  take  Into  account  the  importance  of 
mission  critical  computer  resources  to  the  Army.  The  command  must 
manage  its  computer  intensive  systems  so  they  are  reliable,  meet  user 
requirements,  and  are  supportable  during  their  life  cycle.  In  order  to 
do  so  it  should  be  resourced  to  manage  the  increasing  role  of  computer 
resources  in  weapon  systems,  provide  a  strong  advocate  on  the  AMC 
staff,  and  provide  career  paths  for  software  professionals. 


RECOMMENDATIONS: 

A.  Establish  vvell  rsouroed,  limited  life  Special  Operations  Center 

-  Execute  a  wefl  -  defined  Charter 

-  -  TaskAsslyiment 

—  Define  Authority  and  Supporting  Organization 

-  -  Provide  Sunset  Clause 

-  Provide  for  Mission  to  be  Assumed  by  permanent  Organization 

B.  Create  an  ADCS  for  MCCR 

-  Policy  assistance  and  surrogate  for  HQDA 

-  Management  of  LOSE 

“  Provide  expert  advise/lessons  learned 

-  Track  computer  resource  trends  and  build  strategy 
>  Resource  Advocate 

C.  Establiah  aenior  level  MCCR  S&T  advisor  to  Commander 


Bcport  of  tho  AMC  Software  Task  Forca 
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Provide  One  -  Stop  Support  for  Project  Managers 


TTie  scarcity  of  computer  hardware  and  software  experts  within 
the  Army  makes  it  critical  that  the  available  people  are  used 
effectively,  provisions  are  made  to  nurture  and  develop  a 
competent  staff,  and  functional  duplication  Is  eliminated.  The* 
Life  Cycle  Software  Engineering  Caters  should  become  the 
resportsible  activity  to  ensure  that  this  happens.  As  such,  the. 
must  become  the  single  source  of  software  support  for  PMs. 

RECOMMENDATIONS: 

A.  LOSE  rasponsibie  for  in- house  softMrareangiiMering 

-  Requiranenb  prototyping 

-  Computer  Resource  Planning 

-  Contractor  evaluation  and  selection 

-  Independent  Verification  and  Validation 

B.  LCSE  provides  servtoes  to  PMs,  not  a  "body  sliop* 

-  Focus  is  on  Products  for  PM 

-  Center  Director  Responsible  for  Quality  of  Product 

-  LCSE  Pnovldes  Environment  to  Develop  Software  Competency 

C.  PM/PEO  staffs  Hmtted  to  managers  not  doers 

D.  PMs/LCSE  ensure  software  vteibNity  during  development 

-  Provide  Visibility  into  Formal  Unit  &  Integration  Tests 

-  Enhance  Information  Flow  to  PA&T,  AMSAA,  TECOM,  OTEA 

E.  LCSE  maintenance  activities  under  rigorous  controls 

-  Integrated  Configuration  Management  program 

-  internal  Software  Quality  Program 

-  Subject  to  Process  Review  by  Product  Assurance 
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Build  an  Army  Software  Technology  Center 


The  trend  to  disperse  the  critical  mass  of  technologists  supporting 
sofM^re  and  to  decrease  the  annual  research  and  development 
budget  for  sottvsrare  technology  must  be  reversed.  The  Army  needs 
an  integrated,  effective  approach  to  software  technology  which  will 
provide  a  critical  mass  for  software  tools  and  technology,  serve  as  a 
vehicle  for  technology  insertion,  and  insure  responsiveness  to  Army 
wide  MCCR  needs. 


RECOMMENDATIONS: 

A.  Reaffirm  dedsfcm  to  have  STC  at  Ft.  Monmoutli 

B.  Establish  criticaJ  mass  of  people  and  funding  for  5  years 

-  Inittal  R&D  Budget  of  $1  SM/year 
-Assemble  Staff  of  100 

C.  Establish  rasouroe  source,  concentrate  other  activities 

D.  Create  a  eoftware  technology  affiliates  program 

E.  Run  Software  Engineering  Intern  program  as  part  of  STC 

F.  Define  specifin  technology  insertion  tasks  and  controls 

G.  Assign  technology  proponency  to  STC;  advocacy  at  HQ 

H.  Develop  techiwiogy  program  with  maximum  use  of  commercial  base 
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Organize  to  Grow  Software  Engineers 


Recx)gntze  that  software  engineers  have  different  skills  and  abilities 
than  others.  Army  must  plan  to  grow  its  own  Software  Engineers 
from  within  and  als^^  needs,  to  ensure  their  effective  use.  Provide 
a  mechanism  to  provide  both  technical  and  domain  maturity 
before  putting  Software  Engineers  into  management  positions. 


RECOyyENOATIONS: 

A.  Use  noNvGS- 0854  aeries;  do  not  permit  grandfathering 

-  Establish  Tough  Qualification  Standards  for  854s 

-  Require  Engineering  and  Computer  Educatlon/Experlenoe 

B.  Provide  four  disdnct  levels  of  performance 

-  Intern;  Formal  training  program  for  technical  development 

-  Apprentice;  Develop  domain  experience  at  LCSEC 

-  Jourrreyrnan:  Spread  talent  to  HQ,  PM,  PA&T, ... 

-  Senior:  Key  management  decision  positions 

C.  Establish  Opportunities  for  Senior  Software  Engineers 

-  Require  PM  Sys  ^^m  Engineers  to  have  Software  Competence 

-  Create  MCCR  Software  Positions  at  HQDA  &  MACOM  HQs 

-  Devel .  ’:>''Software  Chief  Engineer"  Positions 

D.  Use  oo- op  program  to  identify  Outstanding  Candidates 

-  Encourage  ieecfog  of  oo  >  op  Employees  into  inter  Program 
~  Early  bonding  with  Organizational  Leadership 
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Eliminate  Confusion  in  Training  Device  Support 


Because  transition  of  life  cycle  support  for  training  devices  and 
systems  has  been  difficult  to  achieve,  AMC  must  ensure  that  an 
organizational  structure  Is  in  place  to  provide  the  life  cycie  software 
engineering  support.  A  solution  needs  to  take  intaaccount  the 
problems  of  resourcing,  support  to  system  specific  devices, 
interoperability,  and  the  inherent  dlfficullty  in  building  a  software 
support  capability. 


RECX)MMENDAT10NS: 

A.  Assign  life  cycle  software  engineering  responsibility  as  follows: 

-TRADOC 

-  -  Systems  used  at  TRADCX^ 

—  Coursewarewhich  is  separable  from  system  softv^e 
-AMC 

-  -  System  specfflc  devices  assigned  to  same  LCSEC  as  system 
—  Generic  systems  to  CECOM  center  at  Ft  Leavenworth 

B.  Quids  prooaes  by  following  rules 

-  Designate  LCSEC  for  each  specific  system  using  above  guidelines 

-  LCSEC  Integrally  Involved  In  development  process 

-  Training  device  developer  programs  resources 

C.  Test  use  Of  Total  Contrak^or  Software  Support  as  alternative 

-  Perform  cost  benefit  analysis  of  concept 

-  Specify  documentation  as  priced  option  to  reduce  risk 


SS-225 

Provide  Virtual  Colocation  with  TRADOC  Centers 


Where  AMC  and  TRADOC  centers  are  colocated,  the  communication 
between  the  two  is  generally  excellent.  Where  the  centers  are 
physically  separated,  communication  suffers.  Communication  In  a 
wide  variety  of  areas  must  be  improved.  Areas  of  importance  include: 
probiem  identlficatton  and  tracking,  requirements  understanding,  * 
configuration  management,  and  test  participation. 


RECOMMENDATIONS: 

A.  Use  electronic  means  to  provide  virtual  colocation 

-  Electronic  Mail 

-  Videoconferencing 

-  Electronic  blackboards 
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Develop  Pilot  Software  Awareness  Program 


The  Army  needs  to  publicize:  (1 )  real  and  near  reaJ  -  time  software's 
pivotal  role  in  fulfilling  Airland  Battle  Doctrir^e,  (2)  software  engineering 
enabling  role  In  developing  and  maintaining  eftident,  effective,  and 
economical  combat  software.  Awareness  of  software’s  force 
multiplication  aspects  will  support  resource  allocations  at  the 
highest  level  of  government. 


REC0MMENDAT10NS: 

A.  Develop  Airiand  Battle  Software  Story 

-  Why  turn  op>eratlonal  battlefield  to  software 

-  How  software  enables  f  utf  lllment  of  Army  future  needs 

-  How  software  Is  providing  combat  ♦orce  multiplier 

-  Why  tactical  software  forms  ever  increasing  part  of  Army’s  budget 

-  Initiatives  Army  Is  taking  to  control  software  cost  and  quality 

B.  Prepare  an  AIrtand  Battle  Software  awareness  brief 

-  Pilot  interactive  video  software  awareness  program 

-  introductory  video  tape 

-  Briefing  slides/viewgraphs  and  script 

C.  Brief  key  Defense  leaders  on  software  role/lnitlatives 

-  Congressional  members  and  staffers 

-  OSD,  ARSTAF.  MACOM,  and  MSC  leaders 

-  General  officers  throughout  Army 

D.  Solicit  and  record  feedback  Information 

-  Ciartty  and  impact  of  briefi.ng’s  message 

-  Capability  to  visualize,  implant,  and  sustain  importanos  of  software 
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Develop  Operational  Software  Literacy  Program 


Army  needs  to  develop  an  Airland  Battle  Software  Awarenesa^Literacy 
program  tor  congressional,  0MB,  OSD,  Joint,  and  Army  leadership 
which  will:  (1)  elevate  their  consciousness  .evel  with  respect  to 
software’s  pivotal  role  in  winning  the  Airland  battle  in  the  1 990  and 
beyond  timeframe,  (2)  address  softvyare  awareness/llteracy  within 
the  Officer  and  NCO  Corps,  and  (3)  support  the  harnessing  of  Gl 
creative  potential  in  using  software  as  a  force  multiplier. 

RECOyMENDAHONS: 

A.  Build  Software  Uteraqf  program  based  on  Pilot  Awareness  Effort 

-  Expand  Army's  Airland  Battle  Software  Story 

-  Developinteractive  Software  Literacy  Program 

-  DevBk3p  interactive  Software  Engineering  Programs 

-  Update  Video  Tape 

-  Update  Briefing  materials 

B.  Execute  Uteracy  Program  whicti  includes 

-  Train -upActiveAnTiy,ANG,andUSAR 

-  Spark  creativity  of  Officer  and  NCO  Corps  with  regard  to  software 

•  UseGI  insight  to  influence  Software  System  Engineers 

C.  Get  to  General  Oficers  to  show  impact  of  softerare 

-  All  General  Officers  Army  wide  to  become  literate 

-  Briefings  should  be  presented  by  s<>ftware  knowledgeable  GO 


SS-233 

Find  Army  Software  Advocates 


Computer  technology  budget  has  decreased  by  order  of  magnitude 
in  last  five  years.  An  advocate  is  needed  at  both  the  WACOM  and 
ARSTAF  levels.  Additionally,  proponency  for  Ute  Cyde  Software 
Engin^ring  appears  confused  with  weapons  system  support 
having  no  effective  proponent. 


RECOyMENOATIONS: 

A.  Find  fightari  for  eofftwara  technology  at  AMC  &  DA  • 

B.  Correct  falKjre  of  AMC  proponent  to  mipport  MCCR 

-  Separately  identify  arxj  track  MCCR  software  support 

-  Provide  for  MCCR  representation  at  HQDA  Budget  Panels 

—  Recognize  that  IM  proponent  supports  MIS/ADP 
—  Tradeoff  between  MI^ADP  arxj  MCCR  at  Appropriate  Levels 
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Establish  clear  Acquisition  Policy  for  Software 


The  Army  should  provide  a  clear,  unambigous  implementation  of 
DODD  5000.29  for  Mission  Critical  Defense  Systems.  Chapter  8 
of  AR  70  - 1  establishes  the  basis  for  such  a  policy,  but  it  needs 
to  be  impiemente(rand  remaining  ambiguities  with  the  AR  25  -  series 
reguiations  needs  to  be  removed.  Realistic  poiicies  and  controls 
applicable  to  PECs  and  PMs  need  to  be  implemented. 


RECOMMENDATIONS: 

A.  Establish  dear  and  concise  definition/process  for  MCCR 

B.  Create  integrated  policy  stream  under  AR  70  - 1  for  MCCR 

C.  Integrate  computer  reeouroe  issues  Into  PM/PEO/AAE  process 

-  UseCRWG  to  help  PM  build  strategy 

-  LCSEC  responsible  for  early  Identification  of  problems 

-  MACOMs  provide  experts  to  help  PEC  review/evaluate  plans 

D.  Require  all  approvals  and  waivers  in  single  document 

E.  MACOMs  maintain  database  on  computer  resource  requirements 

F.  Provide  implementation  in  AR  70-series  regulation 

-  Revise  associated  regulations  simultaneously 

-  Put  detailed  technical  considerations  in  DA  Pamphlet 

G.  Require  consideration  of  life  cycle  tailoring 

H.  Provide  gukJanca  for  evolvfng  new  paradlgms/environment  strategy 
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Clarify  Funding  Policy  for  Software  Support 


Need  to  obtain  clear  -  cut  and  unambiguous  guidance  on  LCSE 
funding  policy  that  will  provide  the  most  efficient  management  of 
LCSE  functions.  Recent  funding  policy  changes  have  streamlined 
the  process,  but  several  residual  issues  must  still  be  addressed. 

RECOyMENOATIONS: 

A.  Determine  where  to  report  manpower  needs  In  BPRR/IIAIIP 

-  Conversion  from  OM A  P2  to  OMA  P7M  scheduled  for  FY  90 

-  Need  to  avoid  separation  of  dollars  and  spaces 

B.  Consider  augmentation  of  OMA  core  funding  in  MDEP  MS2B 

-  Reimburse  OMA  with  ROTE  &  OPA  based  on  ratio  of  core  tasks 

-  Collect  ROTE  &  OPA  funds  by  Increasing  task  overhead 

C.  Limit  use  of  MCM  for  software  improvements 

-  When  associated  with  improvements  to  hardware,  or 

-  When  specific  dollar  threshold  is  exceeded 

-  Otherwise  use  OMA  P7M  process  as  defined  in  current  policy 
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Provide  for  Management  of  Software  Change 


Individual  software  changes  to  systems  need  to  be  Identified,  costed, 
prioritized,  and  approved  through  a  disciplined  change  approval 
process.  Although  costs  for  systems  will  be  estimated  based  on 
the  best  available  models,  the  OMA  P7M  funds  which  are  identified 
need  to  be  experKled  to  get  the  best  possible  value  to  the  Army.  A 
joint  prioritization  must  serve  as  the  basis  for  allocation  of  funds  and 
identification  of  deferred  software  maintenance  and  improvement 
tasks. 

RECOMMENDATIONS: 

A.  CiMifysGftMfara  support  tasks  into  two  simple  categories 

-  Maintenance:  correction  of  defidendes 

-  impnsvements:  new  capabiiities  added 

B.  Define  a  minimum  level  of  sustalnnHint  for  each  system 

-  Define  minimum  levels  to  maintain  Supportabiiity  for  each  system 

—  Delerrnireoostof  nrairTtEyning  Environment 

—  Consider  need  to  maintain  expertise  in  Unique  Languages 
—  Assess  quality  of  Oocumentation/Software  Structure 
—  Level  should  decrease  as  function  of  learning  curve 

-  Consider  sustainment  needs  in  prioritizing  work  across  systems 

-  Detenninetimetooeasesupport  on  case- by- case  basis 

—  Logical  point  to  freeze  configurations 
—  Statistical  Confidence  that  critical  errors  removed 

C.  Conduct  an  annual  joint  AMC/ISCATRADOC  prioritization 

-  Identify  and  cost  out  each  proposed  change 

-  Merge  maintenanoe  and  Improvements  into  one  master  list 

-  PriorttiZBal  propcsais  and  rank  1  -to-N 

-  Fund  appropriate  improvements  through  MCM  process 

-  Allocate  funds  in  priority  order  to  remaining  changes 

-  Re  -  allocate  if  necessary  to  maintain  sustainment  of  selected  systems 

D.  Complete  review  early  30  that  funds  can  be  reprogrammed 

-  identity  impacts  of  funding  shortfalls 

-  Terminate  support  cleanly  as  required 

-  Don’t  plan  on  reestablishing  support  after  it  has  been  interrupted 
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Establish  Internal  Controls  and  Feedback 


Internal  controls  within  MACOMs  need  to  be  used  to  minimize  the  risk 
of  having  software  materiel  weaknesses.  In  general,  existing  controls 
have  failed  to  provide  feedback  and  corrective  actions.  Actions  have 
primarily  been  driven  by  outside  audits,  studies,  and  reports.  Each 
MACOM  should  establish  a  management  and  control  process  to 
identify  and  correct  systemic  weaknesses  regarding  the  development 
and  support  of  mission  critical  software. 


RECOMMENDATIONS: 

A.  Establish  a  formal  process  to  identify/investigate  problems 

-  Identify  system  problems 

-  Create  mechanism  for  problem  feedback 

-  Develop  lessons  learned 

-  Implement  oorrective  actions 

B.  Create  database  to  track  softvrare  issues/problems/solutions 

-  Identify  specific  software  related  issues 

-  Classify  issues  into  problem  areas 

-  Identify  solutions  to  problems 

-  Remove  items  from  database  after  solution  effectiveness  shown 

C.  Assign  responsibility  and  demand  accountability 

-  Establishing  corrective  action  system 

-  Execution  of  specific  recommendations 
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Develop  a  Computer  Resource  Data  Base 


Today's  major  problems  with  software  development  are  not  basic 
technology  problems,  but  failures  In  management.  A  major 
re  -  examination  and  change  In  attitudes  and  practices  concerning 
software  acquisition  is  needed.  A  key  part  of  that  change  in 
attitude  must  be  a  more  comprehensive  view  and  assessment  of 
the  computer  resources  used  In  MCCR  systems. 

RECOyiJENOATlONS: 

A.  Develop  a  database  for  system  computer  resource  information 

-  Establish  compatible  databases  at  each  MSC 

-  Define  criteria  used  to  determine  how  MCCR  are  entered 

-  ktentify  key  resource  information 

—  Host  and  target  harc^vare 
—  Languages  used 
~  -  Design  rrethodoiogies^toois  used 
—  Sof^^aredeveioprnenVsuppQrtenvl^onrnent  characteristics 
—  Funding  information  tosupport  budget  formulation 
—  IdentillcatiorVoost  of  system  change  proposals 

-  Use  as  basis  for  command  management  analysis/reports 

B.  Establish  capability  to  feed  MSC  database  via  DDN 

>  MSC  maintain  data  from  Computer  Resource  Plans 

-  Roll  -  up  and  summary  data  available  for  MACOM  use 

-  Provide  for  tracking  of  Systems  and  resources 

-  Use  to  support  long  range  planning 
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Enhance  Interaction  between  Activities 


Periodic  and  ongoing  activities  should  be  used  to  Impiove 
communication  and  foster  Interchange  of  Information  between  Army 
and  other  DoD  activities  with  an  Interest  In  mission  critical  software. 

The  Life  Cycle  Software  Engineering  Steering  Committee  should 
be  revived  to  foster  cooperation  between  Army  activities.  Support 
to  the  JPCG  -  CRM  should  be  expanded  to  best  utilize  the 
cooperation  between  the  services  on  policy,  technology,  planning, 
and  software  support  matters. 

RECOyMENDATIOMS: 

A.  Re-astabish  quarterly  meetings  of  AnnyLCSEC  Commanders 

-  AMC,TRADOC.  ISC.  HSC,  COE 

-  Resurrect  old  Steering  Committee  Charter 

-Pnovkjetor 

—  General  session  for  Information  sharing 

—  Separate  meetings  for  MACOM  issue  reeoiCition 

-  -  (>)nrteinexpertwa10ng  session  for  specific  probtem  areas 

B.  Provide  regular  General  Oflloer  meetings  with  Steering  Committee 

-  Active  partidpatlon  by  Army  proponents 

-  Provide  forum  for  problem  resolution 

-  Formal  report  by  Steering  Committee 

-  Focus  on  pollcy/tunding  Issue  discussion 

C.  Expand  support  for  JLC  Software  panel 

-  Use  to  gain  leverage  off  other  services  activities 

-  With  DARPA  control  of  ST ARS,  consider  restart  of  Technology  Panel 

-  Establish  common  PDSS  policies  and  procedures  across  services 
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Integrate  Software  Quality  into  Process 


American  quality  organizations  are  typically  considered  "second  class" 
operations.  By  focusing  on  engineering  the  quality  into  the  design  rather 
than  the  "assurance"  aspects,  the  Army  needs  to  force  quality  Into  a 
position  of  preeminence.  We  need  to  ensure  the  crrxjibility  of  our 
quality  organizations  by  using  fairly  senior  people  with  solid  software 
credentials. 


RECOMMENDATIONS: 

A.  FuHy  Integrate  quality  Into  software  development  process 

-  Require  Developer  to  Implement  Total  Quality  Management 
>  Provide  metrics  as  part  of  software  environment 

B.  Hold  LX;SEC  responsible  for  managing  software  development 

-  Support  PM  in  development  of  acquisition  strategy 

-  Provide  product  oriented  management  assistance  to  PM 

-  Conduct IV&Vvvith in -house experts 

-  Ensure  early  identification  of  problems;  information  sharing 

C.  Requiro  LCSEC  to  establish  internal  quality  controls 

-  Establish  quality  standards 

-  Conduct  design  reviews  and  code  audits 

O.  Hold  PA&T  responsible  for  process  oversight 

-  Adequacy  of  contract  provisions 

-  Process  Evaluation 

—  HarlflA/a^^Sof^^a^BOeveloprnent  Process 
—  Integration  of  HarcMere  and  Software 
—  Comporient.systBrn,andqualtficatjon  testing 
-  -  LCSEC  process  evaluation 

-  Identify  systemic  problem  areas 

-  Materiel  Release  /  Software  Version  Release 

-  Fielded  System  Reviews 
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Improve  Software  Configuration  Management 


Configuration  control  of  software  and  management  of  those 
configurations  has  been  based  on  existing  hardware  regulations 
as  implemented  by  the  various  subordinate  commands.  No  standard 
configuration  accounting  systems  or  even  software  numbering 
systems  have  been  selected.  Standardization  activities  need  to 
be  pursued. 


RECOyMENDATIONS: 

A.  Work  t(M^ard  a  MACOM  standard  oonfiguratton  management  tool 

-  Select  commercial  tool 

-  Integrate  into  ^  andard  software  support  environment 

-  Provide standarc  implementation  procedures 

B.  Instttute  a  standard  Computer  Program  Identification  Number 

-  Supplement  NSN  which  only  Identifies  media 

-  Maintain  compatibility  with  other  services 

-  Assign  LCSEC  responsibility  for  CPIN  assignment/management 

C.  Implement  standard  ttutod  Interoperability  control  board 

-  Enface  Configuration  Control  over  Interfaces 

-  Within  BFA  and  between  BFAs 

-  Develop  capability  to  model  and  test  Interfaces 

D.  Facilitate  Softvvare  Reuse 

-  Establish  repository  for  reusable  parts 

-  IssufB  standards/criteria  for  Included  software 

-  Provide  strong  Configuration  Control 
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Implement  Effective  Interoperability  Control 


Army  needs  to  enforce  a  top  -  down  approach  to  develop,  plan,  and 
refine  baselines  to  support  a  “system  of  systems"  approach  to 
Interoperability.  Concepts  which  are  now  stated  at  a  high  level 
must  be  refined  to  define,  model,  evaluate,  and  control  system 
to  system  Interfaces,  interoperability  evaluations  cannot  be 
deferred  until  operational  tests.  A  hardware  basis  is  needed  for 
component  integration  below  the  level  of  the  command  and 
control  nodes. 

RECOyMENOATIONS: 

A.  Creete  Army  Interoperability  Executable  Model 

-  Use  to  evolve  detailed  specifications  from  high  level  requirements 

-  Support  variety  of  levels  of  specification 

-  Simuiate  message  ioading/reoonfiguration 

B.  Accelerate  funding  of  Army  Interoperability  Network  (AIN) 

-  Provide  distributed  C3I  test  suite 

-  -  Sbxiatsrs/Stimulators 

-  -  Highspeed  network 

—  Uriks  to  JointTest  Beds/Testers/Contractors 

-  Support  variety  of  test/evaluation  functions 

-  -  Devetoprriern  and  aocsptEurioe  testing 

—  Regression  arto  Version  Certification  T esting 

—  Software  readbiess  for  Operational  Test 

C.  BuHd  Government  interoperability  knowledge  base 

>  CoAect  information  posessed  by  IV&V  contractors 

•  Use  as  basis  for  further  requirement  development 

D.  Investigate  oomponant  Integration/standardization 

-  Address  hardware  standardization  below  CAC  nodes 

-  Prevent  multiple  development  of  CAC  software 
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SS-324 

Address  Software  as  part  of  Materiel  Release 


Current  regulations  permit,  but  do  not  specifically  require  use  of 
the  Materiel  Release  process  for  software.  The  resulting  confusion 
needs  to  be  resolved  with  a  clear  statement  that  the  release 
process  te  used  to  release  ail  block  improvements  to  software. 


RECOMMENDATIONS: 

A.  Revise  AR  700 -142  and  AMCR  700  -  34  to  addreGsaofhwe 

-  Software  to  be  released  as  block  improvements 

-  Interoperability  statement  required  for  all  software 

-  Ail  software  changes  need  to  follow  release  prooedures 

-  Software  only  releases  eliminate  hardware  specific  statements 

B.  Evaluale  and  recommend  procedures  for  spodal/evoiving  needs 

-  Emergency  releases 

-  Evdutlarary  life  cyde  model 
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SS-a25 

Develop  Responsive  Distribution  Process 


AMC  tactical  computer  systems  Increased  from  85  systems  In  1 980 
to  232  systems  in  1 989,  and  will  continue  to  grow.  The  standard 
logistics  supply  system  Is  not  adequate  for  supporting  software  change 
distribution,  especially  when  major  modifications  to  interoperating 
command  and  control  systems  must  be  accomplished.  Current 
method  of  sending  teams  from  the  LSSEC  will  be  Impractical  as  the 
number  of  systems  continues  to  grow.  Alternative  methods  need 
to  be  investigated  now. 

RECOyMENOATIONS: 

A.  Conduct  experiment  wtth  forward  raplicatfon/dtetrlbution 

-  Establish  AMC  in  -  theater  assistance  center 

-  Electrcnicaily  transmit  software  upgrades  and  documentation 

~  Use  desktop  publishing  capability  to  prepare  documentation 

~  Repiicate  software  and  print  documentation  at  forward  site 

-  Install  and  train  from  forward  site 

B.  BowiDpAiTny  go- to -war  strategy  for  software  upgrades 

C.  Require  consideration  of  extomaBy  programmobie  memory 

>  Could  reduce  the  configuration  burden 

-  Simplify  upgrade  process 

-  Supports  different  software  versions  in  different  theaters 

D.  Deeelop  regulation  w^xlressing  Software  Distribution 
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Provide  Software  Maturity  Management 


Systems  must  be  managed  so  we  avoid  a  “final  exam  mentality."  The 
Army  does  not  now  have,  but  rteeds  to  use  an  approach  for  tracking  the 
maturity  of  software  In  systems.  Deficiencies  must  be  Identified  and 
corrective  actions  taken  before  the  system  reaches  its  formal  testing 
phase.  It  is  critical  that  the  focus  on  system  testing  be  lessened.  The 
Army  must  ensure  that  component  tests  are  properly  structured  and 
the  information  from  them  is  used  to  Identify  and  remove  defidendes. 


RECOMMENDATIONS: 

A.  Develop,  evalueta,  and  then  use  software  metrics 

-  Process  measures 

-  Product  measures 

-  -  observable  behavior  (e.g.  time  to  failure) 

-  -  design  and  oode  attributes 

B.  Require  uae  of  approved  monitoring  tools 

-  Emphaslie  "engineering"  not  "assurance"  aspects 

-  Use  care  In  applying  hardware  type  indicators 

-  Selecl  proven  techniques,  eg. 

—  Deteotdensfty 
—  Testsuffldercy 

—  Detect  cause  arxj  type  distributions 

C.  Use  system  approach  to  show  Intermediate  reaulta 

-  Prototype  evaluation  by  users 

-  Stress  testing  of  system  components 

-  Early  Integration  testing  with  Interoperable  systems 

-  Ak3w"free  play"  testing  prior  to  formal  test 

-  Don’t  allow  schedule  driven  premature  Initiation  of  formal  testing 
O.  Reach  oonaenaua  for  on- going  evaluationa 

-  Agree  on  system  evaluation  criteria  up  -  front 

-  Encourage  LCSEC,  TECOM,  AMSAA,  OTEA  partidpation 

-  Develop  consensus  of  def  idendes 

-  -  Engineering  assessment  of  failure  cause 
—  Corrective  actloris 


^-411 

Enforce  Standard  Software  Cost  Model  Use 


A  variant  of  Boehm’s  COCOMO  software  cost  estimating  model  has 
been  developed  for  Army  use  in  Life  Cycle  Software  Cost  forecasting. 
The  model,  called  SECOMO,  was  validated  but  different  versions  are 
starting  to  appear.  A  standard,  approved  version  should  be  maintained. 
In  addition,  further  refinements  to  the  model  need  to  be  addressed  and 
a  methodology  for  forecasting  development,  in  addition  to  support 
costs,  needs  to  be  deveioped. 


RECOMMENDATIONS: 

A.  Mandale  use  of  one  authorized  version  of  SECOMO  model 

-  Revalidate  MEA  approved  model 

-  Provide  for  uniform  application  aaoss  LCSECs 

-  Verify  oompliarxte  with  field  audits 

B.  Support  further  refinements  to  the  model 

-  Retain  MEA  approval  and  certification 

•  Develop  modifications  to  address  Ada  cost  differenoes 

-  Impiemeritlex>^iedge- based  front  end 

-  Provide  templates  to  address  LCSEC  unique  aspects 

C.  Determine  areas  where  further  improvements  are  necessary 

-  CoOect  actual  cost  data 

-  Assess  actual  against  predicted  requirements 

D.  Conduct  reeeerch  to  develop  model  for  use  In  development 

-  Data  Requirements 

-  Model  Development 


SS-412 

Improve  Interface  into  PPBS  for  Software 


Establish  a  capability  to  capture  total  LOSE  requirements  and  latest 
tunding  guidance  from  multiple  commands  and  appropriations. 
Isolate  and  track  LCSE  costs  through  the  PPBS  process. 


RECOMMENDATIONS: 

A.  Design  a  process  to  capture  LCSE  requirements/guidance 

-  Consistent  with  Computer  jrce  Management  Plans 

-  Reflect  otftput  from  approved  cost  forecasting  mocW 
~  Capture  core  and  system  specific  requirements 

—  OMAdIrectfurKflng 

—  RDTEOPA  tar  improvements  under  MCM  process 
—  OPA  tor  harc^^afe  environment  improvernents 
—  MCA  projects  tor  LCSE  oonstructlon/upgrade 
—  Spaces  and  manpower  authorizations 

B.  Provide  timely  feedback  from  PPBS  decisions 

-  Identity  resources  to  specific  system  needs 

-  Provide  basis  for  reclama/defense 


SS-413 

Identify  and  Capture  Actual  Software  Costs 


In  spite  of  the  ever  increasing  cost  of  software  to  the  Army,  It  is  not 
possible  to  identify  and  track  those  costs.  Actions  need  to  be  taken 
collect  software  costs  both  during  development  and  during  the  support 
phase  of  the  life  cycle.  It  must  be  recognized  that  collecting  hardware 
and  software  costs  together  does  not  provide  sufficient  visibility  into 
the  development  process. 

RECOMMENDATIONS: 

* 

A.  Develop  oommon  data  definitions  across  services 

-  Establish  software  cost  data  collection  criteria 

-  Use  prescribed  Work  Breakdown  System  for  software 

-  Ill  -  service  beds  fa  data  collection  provides  maximum  leverage 

B.  Require  contractors  to  isolate  and  report  softerare  costs 

C.  Establish  standard  procedures  to  report  in -house  software  cost 

D.  Develop  policies  and  instructions  concerning  cost  identification 

-  Use  other  service  policies  as  models 

-  Maintain  historicai  records  In  Computer  Resource  Database 
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SS-421 

Provide  Efficient  Front  End  Loading 


The  Army  evolved  the  concept  of  Post  Depolyment  Software  Support 
into  Life  Cycle  Software  Engineering  approximately  five  years  ago. 
This  action  provided  additional  consideration  of  software  engineering 
at  the  front  enctof  development  rather  than  waiting  until  it  was  time 
for  support.  With  more  resources  required  to  support  the  Increasing 
number  of  transitioned  systems,  it  is  time  to  refocus  resource 
allocation  to  emphasize  early,  high  leverage  actions. 


RECOMMENDATIONS: 

A.  Define  specific  front  end  tasks  to  be  done  in -house 

-  Construction  of  rapid  prototypes 

-  Corrtractorrriaturlty  measurement 

-  Hands- on  of  design  and  code 

-  Internal  IV&V  execution 

B.  Determine  methods  to  Resource  Front  End  Tasks 

C.  Establish  Army  sponsored  FFRDC  for  Acquisition  Assistance 

-  Provide  System  Engineering  Expertise 

-  Focus  on  Command  &  Control  Systems 

-  Expertise  in  Real  -  Time,  Embedded  Computer  Systems 


tcporc 
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SS-422 

Consider  Alternative  Support  Options 


The  concept  of  in  -  house  Army  software  support  envisioned  over 
ten  years  ago  was  never  executed  because  of  resource  constraints. 
Typically,  each  LCSE  uses  a  support  contractor  to  perform  maintenance 
and  improvements  on  the  systems  it  manages.  Sometimes  government 
facilities  are  used,  but  other  times  they  are  not.  There  is  a  need  to 
consider  alternative  support  concepts  with  the  purpose  of  minimizing 
cost  and  freeing  up  government  people  to  focus  on  emerging  systems. 


RECOMMENDATIONS: 

A.  Pick  aoioctPd  systems  to  test  alternative  concepts 

-  Total  contractor  lifetime  software  logistics  support 

-  Use  of  a  Reliability  Improvement  Warranty  concept 

-  Delivery  of  program  generators  not  code;  maintain  at  high  level 
“  Contract  Award  Fees  tied  Directly  to  Field  Software  performance 

B.  Assess  cost  and  risk  of  promising  alternative  concepts 

-  Have  provision  to  acquire  documentation/tools  if  necessary 
~  Conduct  scientifically  planned  experiments 

C.  Establish  guidelines  to  determine  optimum  concepts 

-  GcvarimerTt  -  CkxTtractor  Mix 

-  When  not  to  implement  Organic  Support  Capability 
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SS-423 

Conduct  Cpntracting  Out  Study 


Army  still  does  a  significant  amount  of  in  -  house  development  and 
support  of  ADP/MIS  systems  at  Central  Design  Activities.  These 
systems  are  much  more  similar  to  commercially  available  systems 
than  those  embedded  in  weapon  systems,  and  the  Army  may  be 
mis  -  allocating  Its  people  by  focusing  its  talent  on  these  areas  while 
giving  short  shrift  to  its  tactical  systems.  A  complete  evaluation  of 
the  feasibility  of  contracting  out  these  ADP/MIS  activities  should  be 
conducted. 

RECOMMENDATIONS: 

A.  Evaluate  feasibility  of  freeing  up  TDA  positions  for  MCCR 

-  Formally  study  contracting  out  of  ADP/MIS  CDA  functions 

-  Apply  TDA  surplus  to  MCCR  oriented  software  needs 
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Measure  Efficiency  of  Current  LOSE  Centers 


The  decision  to  use  a  controlled  number  of  LCSE  centers  is  based 
on  a  study  which  is  over  ten  years  old.  No  data  is  available  to 
help  evaluate  the  effectiveness  and  efficiency  of  these  centers. 
Productivity  data  should  be  collected  and  used  to  update  PDSS 
concept  study. 


RECOMMENDATIONS: 

A.  identify  efficiency  measures  for  LCSECs 

>  Cost  per  line  of  code  changed 

-  Productivity  measures 

-  Distribution  of  Activities 

B.  InstitutB  on- going  dafa  ooiiection  effort 

-  Instrument  Support  Environments 

-  Provide  analysis  of  metrics 
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Develop  Software  Engineering  Career  Program 


Provide  a  career  program  with  direct  and  tangible  benefits  to 
employees.  There  must  be  convincing  evidence  encouraging  them 
to  enter  and  stay  in  the  field.  Such  a  program  will  include  the 
following  features:  strict  standards  to  enter  and  progress  in  the 
program,  effective  career  management,  formal  and  continuing  process 
of  training  and  development,  and  good  opportunities  for  high  -  level 
career  progression. 


RECOMMENQAHONS: 

A.  Use  rMMrGS- 0854  series  for  Sofhfvare  Engineering 

B.  Establish  precise  qualification  and  certification  standards 

C.  Establish  Target  Jobs  at  various  professional  levels 
O.  Implement  dual  track  system  with  equal  rewards 

-  Technicat  Research  and  Development;  hands-on 

-  Maregement:  PM/PEO,  HQDA,  MACOM,  MSC  management 

E.  Provide  tangeable  Inoentlves  at  each  level 

-  Application  and  academically  oriented  education  opportunities 

-  Rapid  pnomofon 

-  Minilmum  holdover  at  GS- 12  levels 

F.  Get  salary  levels  competitive  with  liKfustry 
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SS-432 

improve  Incentives  for  Military  Software  Experts 


The  Army  needs  to  recxDgnIze  the  importance  of  Software  to  its  war 
fighting  capability  and  stop  discouraging  and  frustrating  those  young 
officers  with  software  talent  and  education.  A  process  needs  to 
be  developed  to  ensure  software  capability  is  used  as  a  criteria 
when  assigning  Program  Managers  to  computer  intensive 
projects. 


RE(X>MMENDAT10NS: 

A.  Brviden  career  path  to  General  Officer 

B.  Provide  Software  Understanding  for  518 

C.  Eliminate  53A  classification;  use  25B  instead 

D.  Provide  for  Functional  Automators 

E.  Tr»  t  software  intensive  positions  as  command  assignments 

F.  AERB  identify  masters  degree  in  software  for  MCCR  PM  positions 

G.  Provide  additional  software  intensive  add-on  to  DSMC  PM  course 

H.  Accredit  USMA  Software  Engineering  Department 


SS-433 

Establish  Career  Subprogram  Management 


A  Strong  career  management  Infrastructure  Is  necessary  in  order  for 
the  Army  to  attain  maximum  return  on  investment  in  Software  Engineering 
•  personnel.  As  the  job  series  for  Computer  Engineers  is  Implemented, 
intensive  management  will  be  necessary  to  ensure  that  proper  and 
effective  starvjards  are  developed,  only  well  qualified  engineers  are 
admitted  to  the  program,  each  software  engineer’s  technical  and 
managerial  maturation  is  planned  and  executed. 


RECOMMENDATUDNS: 

A.  Establish  Software  Engineering  Subprogram  manager 

-  Part  time  assignment 

-  Ratad  on  measures  of  program’s  success 
>  Predude  sbw  start -up  process 

B.  Estabiteh  neNvork  of  Software  Engineering  Mentors 

-  WorKwith  high  potential  00 -op students 

-  Authorize  ofters-  to-  hire  into  Software  Engineering  Intern  Program 

-  Work  with  Activity  Career  Program  Manager 

-  Establish  one  at  each  MSC 

C.  Establish  Temporary  Career  Management  Staff 

-  Full  time  support 

-  Interface  with  Personnel 

-  Establish  qualifications;  review  job  standards 

-  Set  up  and  administer  Software  Engineering  Review  Board 

D.  Write  E&SACTEDS  Master  Training  Plan 
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Provide  Job  Challenge  for  Software  Engineers 


Successful  complex  software  programs  use  a  government  acquisition 
force  1 0%  of  the  size  of  the  contractor's  software  development  group. 
Army  systems  seldom  can  muster  a  force  this  large.  Need  to  effectively 
use  the  people  we  have,  yet  realize  that  they  need  some  hands  -  on 
experience  to  maximize  their  competence. 


RECOMMENDATIONS: 

A.  Channel  Sofhfvare  Engineers  into  high  leverage  activities 

~  Concept  definition,  prototype  development 

-  Software  strategy,  operational  concepts,  specifications 

-  source  selection,  program  management 

-  Quality  assurance,  configuration  management 

B.  Develop  means  to  maintain  proficiency 

-  Identify  high  ~  tech  software  intensive  positions 

-  Rotate  software  engineers  Into  high  -  tech  positions 

-  LCSEC  provide  variety  of  skill  building  assignments 

-  Provide  for  affiliates  in  software  research  organizations 

C.  identify  specific  skills  and  assess  as  part  of  IDP  reviews 

-  Design  merits  of  variety  of  software  paradigms 

-  Portabilty  and  re  -  usability  aspects  of  application  code 

-  Evolving  sofNvare  methodologies 

-  Domain  related  expertise 


APPENDIX  C 


Implementation  Obstacles  and  Schedules 


“Ches^iire  -  Puss,"  said  Alice,  "Would  you  tell  me, 
piea^,  which  way  I  ought  to  go  from  here?* 

That  depends  a  good  deal  where  you  want  to  go  to.* 
said  the  cat. 

"I  don’t  care  much  where."  said  Alica 

"Then  It  doesn’t  matter  which  way  you  go,"  said  the  cat 

"...  So  long  as  I  get  somewhere,"  Alice  added  as  an 
explanation. 

"Oh,  you're  sure  to  do  that,"  said  the  cat.  "It  only  you 
walk  long  enough." 


Alice’s  Adventures  In  Wonderland 
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